3 ms·

Thanks. But why are methods removed from types defined this way? Is there a good discussion about this somewhere?

• tapirl 4y ago
  Go tries to make each design element orthogonal. Type definition is not type embedding. There may be some discussions about this, hidden in the go-nuts forum. But I don't know how to filter them out.
• morelisp 4y ago
  I'd say prior to generics, removing methods but keeping the same layout was the main reason to use this kind of declaration for non-primitive types.
• skybrian 4y ago
  Go doesn’t have inheritance. Defining one type in terms of another is not a subclass. It has embedding, which is a close substitute based on composition, but it isn’t the same. See: https://go.dev/doc/faq#inheritance https://go.dev/doc/faq#inheritance and https://go.dev/doc/effective_go#embedding https://go.dev/doc/effective_go#embedding It’s a little confusing because for primitive operations, it kind of looks like Go has inheritance, but this isn’t true for user-defined methods. (And automatic casting might in some cases compound the confusion.)
  • morelisp 4y ago
    > automatic casting might in some cases compound the confusion. This is why you should always be careful to distinguish conversions (which aren't automatic) from assignment of untyped constants/literals (which does automatically attach the type, but isn't casting).
• twic 4y ago
  FWIW, it's the same in Haskell: data T1 = T1 Int m :: T1 -> () m t = () newtype T2 = T2 T1 main :: IO () main = let t2 = T2 (T1 23) v = m t2 in return () Gets: main.hs:11:15: error: \* Couldn't match expected type `T1' with actual type `T2' \* In the first argument of `m', namely `t2' In the expression: m t2 In an equation for `v': v = m t2 | 11 | v = m t2 | ^^