3 ms·

I'm not sure how you concluded that I said interface{} is a subtype of all other types. Perhaps you meant supertype? Also, from “Foo <: Bar”, you can't automat

I'm not sure how you concluded that I said interface{} is a subtype of all other types. Perhaps you meant supertype? Also, from “Foo <: Bar”, you can't automatically conclude that “[]Foo <: []Bar”. That requires the additional assumption that [] is a covariant type constructor, which in Go it isn't.

burntsushi 10y ago
I didn't conclude that at all. It is trivial to produce a contradiction if you assume A <: B because Go will not let you substitute A in place of B for every type in which B occurs. Therefore A is not a subtype of B. This has nothing to do with []A <: []B.
- catnaroek 10y ago
  But that's not at all what subtyping means! It doesn't mean that you can substitute every occurence of “A” with “B” in the program text. It means that every term of type “A” also has type “B”. (Source: I have TaPL p. 182 right in front of me.)
  - burntsushi 10y ago
    OK, I see where I was wrong now. You are right to emphasize the word "term" because that's precisely the detail I was missing. I can no longer come up with a contradiction. The next obvious step is getting an answer to "what is the meaning of saying Go doesn't have subtyping?", which is essentially what you asked above: > What distinction between coercion and subtyping are you making? But this is a question for pcwalton, not you. :-) However, I have some thoughts on the matter. While exploring the extent of my wrongness, I found it very interesting that the Go language spec doesn't mention the words "subtype" or "polymorphism" or "structural" at all. The FAQ mentions "subtype" and "covariance," but doesn't lead to anything conclusive. What I think this means is that the language designers of Go probably don't think of interfaces as being tied to the formal notion of subtype, but rather that of assignability or coercions. This just takes us in a circle though, which leads me to guess that this is a simple matter of two groups of people having different names for the same thing.
    - catnaroek 10y ago
      The litmus test for “typeness” is to ask whether it makes sense to ask whether a term has the type in question. For example, it makes sense to ask whether 2 has type string, and the answer is “no”. But it doesn't make sense to ask whether 2 has type 3 - the closest thing to an answer is “what the hell I don't even?” Then: (0) Structs and interfaces are unarguably types. (1) If a struct S has all the methods required by an interface I, then every term of type S also has type I. As for coercions, they are one possible implementation of subtyping. Another possible implementation is guaranteeing that, whenever “Foo <: Bar”, then “Foo” and “Bar” have a common in-memory representation. But languages shall never be conflated with their implementation details!
      - burntsushi 10y ago
        Yes, I think pcwalton saying that Go doesn't have subtyping is very confusing. What I think he was trying to say was that Go's subtyping is strange because everything is invariant, and that the use of coercions makes the questions you initially raised perhaps not so interesting. For example, if you start with some base assumptions about which type constructors in Go are invariant, e.g., pointers, slices, arrays, etc., then you could feasibly come up with a rule like this: If T <: U, then Foo<T> <: Foo<U> if Foo's type parameter doesn't appear within an invariant type constructor in the definition of Foo. If a rule like that is all you need (and those types of rules have precedence in Go, like whether a type permits equality comparisons or not), then I think that more or less backs up pcwalton's point that subtyping isn't necessarily the thing you have to worry about when adding parametric polymorphism to Go. It's the other stuff, like the mentioned zero values and presence of `nil`.
        catnaroek 10y ago
        The concern I initially raised is just that retrofitting parametric polymorphism into a statically typed language with subtype polymorphism and a sizeable codebase worth not breaking... has a history of not going so well. Although zero values are inelegant, I don't see why they would interact so badly with parametric polymorphism. In Rust terms, it's as if every type implicitly implemented the Default trait. (EDIT: You're right, steveklabnik. It's closer to Default than to Zero. Thanks!) As for nil, I'd rather not comment, since I'm not familiar with the specifics of how it works in Go. (But a previous conversation with pcwalton made it perfectly clear that it doesn't work the same as in Java or .NET.)

burntsushi 10y ago

I didn't conclude that at all. It is trivial to produce a contradiction if you assume A <: B because Go will not let you substitute A in place of B for every type in which B occurs. Therefore A is not a subtype of B. This has nothing to do with []A <: []B.

catnaroek 10y ago
But that's not at all what subtyping means! It doesn't mean that you can substitute every occurence of “A” with “B” in the program text. It means that every term of type “A” also has type “B”. (Source: I have TaPL p. 182 right in front of me.)
- burntsushi 10y ago
  OK, I see where I was wrong now. You are right to emphasize the word "term" because that's precisely the detail I was missing. I can no longer come up with a contradiction. The next obvious step is getting an answer to "what is the meaning of saying Go doesn't have subtyping?", which is essentially what you asked above: > What distinction between coercion and subtyping are you making? But this is a question for pcwalton, not you. :-) However, I have some thoughts on the matter. While exploring the extent of my wrongness, I found it very interesting that the Go language spec doesn't mention the words "subtype" or "polymorphism" or "structural" at all. The FAQ mentions "subtype" and "covariance," but doesn't lead to anything conclusive. What I think this means is that the language designers of Go probably don't think of interfaces as being tied to the formal notion of subtype, but rather that of assignability or coercions. This just takes us in a circle though, which leads me to guess that this is a simple matter of two groups of people having different names for the same thing.
  - catnaroek 10y ago
    The litmus test for “typeness” is to ask whether it makes sense to ask whether a term has the type in question. For example, it makes sense to ask whether 2 has type string, and the answer is “no”. But it doesn't make sense to ask whether 2 has type 3 - the closest thing to an answer is “what the hell I don't even?” Then: (0) Structs and interfaces are unarguably types. (1) If a struct S has all the methods required by an interface I, then every term of type S also has type I. As for coercions, they are one possible implementation of subtyping. Another possible implementation is guaranteeing that, whenever “Foo <: Bar”, then “Foo” and “Bar” have a common in-memory representation. But languages shall never be conflated with their implementation details!
    - burntsushi 10y ago
      Yes, I think pcwalton saying that Go doesn't have subtyping is very confusing. What I think he was trying to say was that Go's subtyping is strange because everything is invariant, and that the use of coercions makes the questions you initially raised perhaps not so interesting. For example, if you start with some base assumptions about which type constructors in Go are invariant, e.g., pointers, slices, arrays, etc., then you could feasibly come up with a rule like this: If T <: U, then Foo<T> <: Foo<U> if Foo's type parameter doesn't appear within an invariant type constructor in the definition of Foo. If a rule like that is all you need (and those types of rules have precedence in Go, like whether a type permits equality comparisons or not), then I think that more or less backs up pcwalton's point that subtyping isn't necessarily the thing you have to worry about when adding parametric polymorphism to Go. It's the other stuff, like the mentioned zero values and presence of `nil`.
      - catnaroek 10y ago
        The concern I initially raised is just that retrofitting parametric polymorphism into a statically typed language with subtype polymorphism and a sizeable codebase worth not breaking... has a history of not going so well. Although zero values are inelegant, I don't see why they would interact so badly with parametric polymorphism. In Rust terms, it's as if every type implicitly implemented the Default trait. (EDIT: You're right, steveklabnik. It's closer to Default than to Zero. Thanks!) As for nil, I'd rather not comment, since I'm not familiar with the specifics of how it works in Go. (But a previous conversation with pcwalton made it perfectly clear that it doesn't work the same as in Java or .NET.)