I 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)

Sorry 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

> `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.