Generic interfaces are going to be implemented later too if I'm reading correctly. So no real surprises there :). I guess the only surprise yet is that generic interfaces aren't supported, so generic methods physically can't satisfy any interface
Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1].
Or to look at that from another angle, if you were to define a Trait which has generic methods that Trait won't be "dyn-compatible" meaning that you can't do dynamic dispatch with this trait, which may be irrelevant to you (if you don't want dynamic dispatch anyway) or a showstopper (if you needed it, now your project won't compile).
That is another way of looking at it, but given the topic, you're gonna have to expand or contextualise that. I Rust a fair bit, and only barely follow.
Actually in hindsight I think my perspective was less helpful because you can write a dyn compatible trait with a generic method it's just that you can't call the method via the trait objects, dynamic dispatch isn't possible for your function. So the original way to think about it was superior.
Is it because of the kinda built-in duck typing, for want of a better word? The thing where if you have a method (or methods) that matches the signature of method(s) of an interface, you implement the interface without explicitly declaring so?
More specifically, it is because of interface type assertions – the fact that if you have a value of some interface type (e.g. `any`), you can dynamically assert that it is another interface type (e.g. `io.Reader`). A good example of that is `io.Copy`: https://cs.opensource.google/go/go/+/refs/tags/go1.26.3:src/...
This aspect is what prevents you from statically knowing which interface-implementations you need to generate for a specific concrete type. There could always be new ones added at runtime.
Still, in this case, half the feature is better than none at all, IMO.