4 ms·

The answer is complete. I just make some additional explanations here. 1) is totally generics unrelated. package main type T1 int func (T1)

by tapirl 4y ago

The answer is complete. I just make some additional explanations here. 1) is totally generics unrelated. package main type T1 int func (T1) M() {} type T2 T1 func main() { var t2 T2 t2.M() // t2.M undefined } The fishTank should be defined as type fishTank struct { container[fish] } instead. 2) is a temporary restriction, among many in the Go 1.18. Some of the restrictions will be removed from future Go versions. ref: * https://go101.org/generics/101.html https://go101.org/generics/101.html * https://github.com/golang/go/issues/50646#issuecomment-1023706545 https://github.com/golang/go/issues/50646#issuecomment-10237... * https://github.com/golang/go/issues/51257 https://github.com/golang/go/issues/51257 * https://github.com/golang/go/issues/51338 https://github.com/golang/go/issues/51338 * https://github.com/golang/go/issues/52474 https://github.com/golang/go/issues/52474 * https://github.com/golang/go/issues/52509 https://github.com/golang/go/issues/52509 * https://github.com/golang/go/issues/52531 https://github.com/golang/go/issues/52531 * https://github.com/golang/go/issues/52614 https://github.com/golang/go/issues/52614

morelisp 4y ago
Re. "temporary restriction": Although there's agreement something should improve around `comparable`, there's no concrete design approved to solve it. It may persist for many versions, or indefinitely. (Vs. e.g re-enabling better type inference where the goal is known and it's "just" implementation work.)
- tapirl 4y ago
  There will be some permanent restrictions in Go custom design, but I think the `comparalbe` one is not one of them. My personal prediction is it will be solved before Go 1.21.
timbray 4y ago
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 | ^^

by tapirl 4y ago

morelisp 4y ago

Re. "temporary restriction": Although there's agreement something should improve around `comparable`, there's no concrete design approved to solve it. It may persist for many versions, or indefinitely. (Vs. e.g re-enabling better type inference where the goal is known and it's "just" implementation work.)

tapirl 4y ago
There will be some permanent restrictions in Go custom design, but I think the `comparalbe` one is not one of them. My personal prediction is it will be solved before Go 1.21.

timbray 4y ago

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 | ^^