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.
1
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
Primitive types and user-defined types being totally different and requiring totally different code to work with them is very ugly and makes me feel like I'm dealing with Java. This proposal doubles down on that instead of at least not making an existing problem any worse.
2
1
So, for example, with both the existing interfaces and these contracts (which I think should really be 1 feature) you end up needing to define wrappers, with everyone defining their own, and needing to implement these methods over and over again. I don't really understand it.
1
1
There's serious a need for the standard library to define some basic contracts and provide wrappers around the built-in types so people can reuse those instead of making their own. However, this smells a lot like Java. I don't see any benefits from forcing both int and Integer.
So, once you have those standard types, the next step on the Java path is to provide auto-conversion to and from them for convenience since it's painful. These are solutions to an unnecessarily created problem though. In terms of deciding between boxing and specialized code...
1
1
... Swift generics simply treat that as an optimization decision, which you can force. It can either reuse the code or specialize it. It also doesn't need to actually force boxing (heap allocation for indirection), but rather it can be generic across different sizes of types.
1
Show replies