Jacob McCollum

I don't really have a horse in this race, but I find this proposal interesting and wanted to put down my thoughts. Based on what I see here: https://go.godbolt.org/z/1fz9s5W8x This:...

> I don't think you are solving the [problems from the design doc](https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods), though: I'm sure that's true, I probably would benefit from reviewing it again. To be fair, though,...

> The solution you suggest seem a variation on the second option here. I suggested a couple of different things, but yes, one of those suggestions would appear similar to...

> and disallow type assertion from empty interface to struct/type which contains methods with type parameters. Can you explain this part further? It seems to me that this would not...

@Merovius It seems like the 2 largest problem areas you focus on are: 1. Generic methods during reflection 2. Generic methods on interfaces I'm not sure I understand why it...

> These are real costs, and they should have a commensurate benefit. If the only benefit is the ability is to chain method calls, that doesn't seem like a good...

The addition of `Union` might make this a bit more complicated. The `expr3` example _technically_ requires infinite lookahead to be unambiguous for all possible inputs. In practice a sufficiently large...

It's now October 2019, I take it this is still not enabled? Is there an ETA?

`go run` compiles your code to a native executable and runs that, but Gophernotes is using an interpreter under the hood (`gomacro`, a link is in the README for this...

I think I also have a use case for a `Not` type: I have a class, something like this: ```python class Field(Generic[T]): kind: FieldKind[T] # has many subclasses, like StringKind,...