I'm liking this next iteration on Go generics more:
go.googlesource.com/proposal/+/mas
Conversation
Replying to
I don't like how they approached interfaces (i.e. not explicit interface contracts but rather structural matches) and prefer this approach, but I don't agree with having these as separate features. That doesn't make sense to me. It should be a unified system for different uses.
1
1
Replying to
I think that is largely due to the code compatibility guarantee. Maybe that wouldn't have been possible with an extension to interfaces?
1
1
Replying to
I would change "Why not use interfaces instead of contracts?" to "Why not use contracts instead of interfaces?" and throw away interfaces. I don't like how they did interfaces. It would be nicer to be able to use a subset of (methods in) contracts as dynamic objects instead.
Replying to
That's an interesting point. If they made contracts a strict superset of interfaces, new code could use contracts for the same purpose and interfaces could eventually be deprecated.
1
3
Replying to
I don't agree with a lot of the details / choices when considering it from a fresh language design perspective but of course there are a lot of backwards compatibility issues and existing design choices leading it to be this way. It's really not how I would approach this though.
1
1
Show replies