3 ms·

This seems somewhat strange to me (and I don't just mean hard on the eyes): func (o Option[T]) Unwrap() T How does Go know that T is a type parameter here

This seems somewhat strange to me (and I don't just mean hard on the eyes): func (o Option[T]) Unwrap() T How does Go know that T is a type parameter here, and not a concrete type named T?

deleted 5y ago
[deleted]
masklinn 5y ago
Reading the specification (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#generic-types https://go.googlesource.com/proposal/+/refs/heads/master/des...) this flows from the type being declared generic, Go will (currently at least) require the receiver to be similarly generic, no specialisation, and no method constraints: > Generic types can have methods. The receiver type of a method must declare the same number of type parameters as are declared in the receiver type's definition. They are declared without any constraint. // Push adds a value to the end of a vector. func (v *Vector[T]) Push(x T) { *v = append(*v, x) } > The type parameters listed in a method declaration need not have the same names as the type parameters in the type declaration. In particular, if they are not used by the method, they can be _.
4ad 5y ago
Because it can only be a type parameter. There is no specialization. (TBH I think that's a mistake because if prevents a solution to the Expression Problem.)
- masklinn 5y ago
  I don't think that's an issue, specialisation is a real edge case (e.g. Rust still doesn't have userland specialisation despite having always had generics) and it's easy to make mistakes with it (e.g. C++'s `vector<bool>` though it's probably less of an issue if you can only specialise functions). That methods can't be parametric is still annoying though because it means utility methods can't have generic parameters unrelated to the subject e.g. can't define a map or fold method, because there's nowhere to put the output type, it has to be a free function instead. But it's not like adding the generic spec thing between the subject and the method name would be a big issue so that can always be added later after the MVP has been exercised a bit. A related "missing bit" which I'd guess they want more feedback before adding would be "conditional methods" aka methods which are only present if the generic types of the subject have a specific property (e.g. in Rust it's common for the generic container to be unbounded but for functions to be bounded on specific traits).
  - 4ad 5y ago
    Adding it later is not impossible, but unfortunately is not that easy either. Ignoring the very high bar for changing Go in general, doing it this way has implementation consequences that would have to be undone. Also the spec change is not just a matter of adding more stuff, but it requires reformalization of the existing semantics because interfaces are already rank-2 types, you just can't see it yet. This feature interacts with interfaces. It's very unfortunate thay didn't do this from the start. The original paper that introduced Go generics had this and used to to solve the Expression Problem.

This seems somewhat strange to me (and I don't just mean hard on the eyes): func (o Option[T]) Unwrap() T How does Go know that T is a type parameter here, and not a concrete type named T?

deleted 5y ago

[deleted]

masklinn 5y ago

Reading the specification (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#generic-types https://go.googlesource.com/proposal/+/refs/heads/master/des...) this flows from the type being declared generic, Go will (currently at least) require the receiver to be similarly generic, no specialisation, and no method constraints: > Generic types can have methods. The receiver type of a method must declare the same number of type parameters as are declared in the receiver type's definition. They are declared without any constraint. // Push adds a value to the end of a vector. func (v *Vector[T]) Push(x T) { *v = append(*v, x) } > The type parameters listed in a method declaration need not have the same names as the type parameters in the type declaration. In particular, if they are not used by the method, they can be _.

4ad 5y ago

Because it can only be a type parameter. There is no specialization. (TBH I think that's a mistake because if prevents a solution to the Expression Problem.)

masklinn 5y ago
I don't think that's an issue, specialisation is a real edge case (e.g. Rust still doesn't have userland specialisation despite having always had generics) and it's easy to make mistakes with it (e.g. C++'s `vector<bool>` though it's probably less of an issue if you can only specialise functions). That methods can't be parametric is still annoying though because it means utility methods can't have generic parameters unrelated to the subject e.g. can't define a map or fold method, because there's nowhere to put the output type, it has to be a free function instead. But it's not like adding the generic spec thing between the subject and the method name would be a big issue so that can always be added later after the MVP has been exercised a bit. A related "missing bit" which I'd guess they want more feedback before adding would be "conditional methods" aka methods which are only present if the generic types of the subject have a specific property (e.g. in Rust it's common for the generic container to be unbounded but for functions to be bounded on specific traits).
- 4ad 5y ago
  Adding it later is not impossible, but unfortunately is not that easy either. Ignoring the very high bar for changing Go in general, doing it this way has implementation consequences that would have to be undone. Also the spec change is not just a matter of adding more stuff, but it requires reformalization of the existing semantics because interfaces are already rank-2 types, you just can't see it yet. This feature interacts with interfaces. It's very unfortunate thay didn't do this from the start. The original paper that introduced Go generics had this and used to to solve the Expression Problem.