4 ms·
Type aliases (type X = Y) are a niche feature and not meant for this use case. If you had done e.g. type X Y you would have had more success.
by sagichmal 7y ago
Type aliases (type X = Y) are a niche feature and not meant for this use case.
If you had done e.g. type X Y you would have had more success.
- whateveracct 7y agoSorry I miswrote. I meant `type X Y` by "type alias" (terminology from other languages) `type X Y` is still affected - you will 100% _not_ have more success :) Proof (using JSON this time): https://play.golang.org/p/erfcSIe-Z7b https://play.golang.org/p/erfcSIe-Z7b
- masklinn 7y ago> `type X Y` is still affected - you will 100% _not_ have more success :) type X Y neither inherits methods nor forwards anything (what struct embedding does), so you need to know about the protocol (which you're not told because it decides to just encode the bytes), and then you need to implement its methods on the newtype explicitly forwarding them to the underlying one. TBF this is a pretty awful case as Go just goes and generates garbage without prompting.
- masklinn 7y agoI think the OP simply wrote them the wrong way around, because `type X = Y` would not have broken anything as it'd make X a trivial alias to Y, and thus would not be losing anything. Even the reflected name doesn't change from the original. type X Y however does create an entirely new type which is physically identical to the original but logically unrelated (without any of the methods or anything). Which is fine in the sense that it's what OP was looking for (completely independent types) but less so in that it doesn't forward any method, and it's not necessarily clear how you'd do that (type conversion, which looks really shitty when it involves pointers)