If anyone is interested in playing with generics in Go, here you go: https://go2goplay.golang.org/
//full-blown tuple support
var person (string, string) = ("John", "Doe")
//records are just tuples with named fields, but can use existing struct access syntax.
var point #{x: int, y: int, z: int} = #{x: 1, y: 2, z: 3}
//due to structural typing, we can just use a type alias
type Person = (string, string)
type Point = #{x: int, y: int, z: int}
var person Person = ("John", "Doe")
var point Point = #{x: 1, y: 2, z: 3}
//or just infer
person := ("John", "Doe")
point := #{x: 1, y: 2, z: 3}
//destructure
fname, lname := person
//destructure record/tuple
{x, y, z} := point
//destructure array or slice (c is always slice)
[a, b, ...c] := myArray
//pattern matching on tuple
switch person {
case ("John", "Doe"): //do exact match
case ("John", _): //only match first name
case (fname, lname): //use new variables
default: //this is the same as `case _:`
}
//pattern matching on record or struct
switch point {
case {x, y, 0}: //do stuff with variable match
case {1, 1, 1}: //do stuff with exact match
default: //do stuff
}
//same style of error handling with more flexibility
switch getPointWithPossibleError(point1, point2) {
case (_, {type: "error1", msg}): //handle error 1
case (_, {type: "errorN", msg}): //handle error N
case ({x, 0, 0}, _): //handle exceptional case
case ({x, y, z}, _): //handle default case
}They then go on to say that they needed to revisit the design in the square brackets case to insert the keyword “type” whenever generics were used, which means this example would presumably become c<type d, type e> which resolves the ambiguity.
It seems more likely it was an issue discovered atbut not revisited when the issue was fixed, and now inertia is keeping it as is.