Awad Diar

Hmmh, maybe if we step back a little, the problem can be reframed because I am not sure that non-parametered types should even support parametered methods. Rather, I feel that...

That's what I thought too initially but then I edited to be more conservative. For instance, does `HasIntIdentity` implement `HasIdentity`? This looks like introducing some kind of variance. Also, S...

I may be mistaken but it makes more sense to me to consider whether HasIntIdentity implements HasIdentity than the opposite. The same way each comparable type has a different version...

Well I think we understand things a bit differently. HasIntIdentity implementing HasIdentity may mean that there is existence of a type argument for which HasIdentity is HasIntIdentity. On the other...

Yes, I am not sure that HasIdentity1 should even be possible, the same way S as defined in the proposal seems strange to me. I would consider allowing parametered methods...

@jpap [edit] Sorry, nvm.. it actually just works already. I fail to see why we would need uninstantiated parametric methods on instantiated or non-generic types. I must be missing something....

As far as I'm concerned, I don't find the statement too reductive wrt the explanations that have been given. This looks very non-trivial to implement for a minor gain in...

I may be wrong but I think that reflect allows to create composites of already known types. I imagine that these types could be used as type arguments to generic...

To add a use-case, when compiling with the go compiler, it allows us to recover from panics by displaying a relevant message in the browser.