4 ms·
To be replaced by the surprise when you figure out these methods don't implement interfaces. Still, in this case, half the feature is better than none at all,
by ncruces 5mo ago
To be replaced by the surprise when you figure out these methods don't implement interfaces.
Still, in this case, half the feature is better than none at all, IMO.
- nasretdinov 5mo agoGeneric 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
- ncruces 5mo agoI didn't see anything beyond "this doesn't prevent us from doing it" yet. Did you?
- kbolino 5mo agoGeneric 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]. [1]: https://doc.rust-lang.org/reference/items/traits.html#r-items.traits.dyn-compatible.associated-functions https://doc.rust-lang.org/reference/items/traits.html#r-item...
- tialaramex 5mo agoOr 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).
- dwattttt 5mo agoThat 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.
- tialaramex 5mo agoActually 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.
- Merovius 5mo agoFWIW I found, so far, that bringing up dyn-compatibility to Rust people was very useful in helping them understand why Go's interfaces won't ever have generic methods. The one additional piece of information you need is that in Go, all interfaces are supposed to be trait objects. The exception are union-elements, but that's really a restriction the Go team is trying to remove, not a model to base more features on.
- EdwardDiego 5mo agoIs 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?
- 9rx 5mo ago> for want of a better word Structural typing is the term typically used to describe "static duck typing".
- catlifeonmars 5mo agoI’d describe structural typing as a special case of duck typing FWIW.
- 9rx 5mo agoI suppose. That special case is that it is evaluated statically, whereas duck typing is evaluated dynamically. That's the whole difference between them. They are otherwise identical concepts. But who is to say that dynamic evaluation isn't the special case?
- Merovius 5mo agoMore 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/io/io.go;l=408 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.
- deleted 5mo ago[deleted]