I wonder if Go could avoid full genetics by supporting union types, as seen in languages like Ceylon and TypeScript.
For example, you could declare a function as Foo(thing string | []int). In other to use "thing" you'd need to do a type assertion. That'd allow "generic" functions where the author could decide which types to support, without going all the way to generics, which tend to open a few cans of worms. Same thing for structs and such. Obviously this has an impact on internal layouts; union values would need an internal type tag similar to interfaces.
With this in mind, I would hope that Go could get better pattern matching with destructuring; switch statements currently only allow you to extract one value, and it's confusing that a single name is shared between all cases. But I'd love to be able to do something like:
switch thing {
case s := string:
...
case [x, y] := []int if len(thing) == 2:
...
}
or whatever.
If we could get proper Rust-style enums on top of that (with appropriate pattern matching) that'd also be neat.
There's no amount of union types that will save you if you want to write a polymorphic, type safe map/filter/reduce function. These functions need to be generic over containers.
At best, with this union type hack what you'll recover is similar to "ad hoc" polymorphism, not true parametric polymorphism.
TypeScript has support for union types and generics because they aren't interchangeable. The purpose of generics is to avoid having to duplicate code or list every possible type as an input.
Comments
I wonder if Go could avoid full genetics by supporting union types, as seen in languages like Ceylon and TypeScript.
For example, you could declare a function as Foo(thing string | []int). In other to use "thing" you'd need to do a type assertion. That'd allow "generic" functions where the author could decide which types to support, without going all the way to generics, which tend to open a few cans of worms. Same thing for structs and such. Obviously this has an impact on internal layouts; union values would need an internal type tag similar to interfaces.
With this in mind, I would hope that Go could get better pattern matching with destructuring; switch statements currently only allow you to extract one value, and it's confusing that a single name is shared between all cases. But I'd love to be able to do something like:
or whatever.If we could get proper Rust-style enums on top of that (with appropriate pattern matching) that'd also be neat.
There's no amount of union types that will save you if you want to write a polymorphic, type safe map/filter/reduce function. These functions need to be generic over containers.
At best, with this union type hack what you'll recover is similar to "ad hoc" polymorphism, not true parametric polymorphism.
TypeScript has support for union types and generics because they aren't interchangeable. The purpose of generics is to avoid having to duplicate code or list every possible type as an input.