6 ms·

If anyone is interested in playing with generics in Go, here you go: https://go2goplay.golang.org/ https://go2goplay.golang.org/ https://go2goplay.golang.org/p

If anyone is interested in playing with generics in Go, here you go: https://go2goplay.golang.org/ https://go2goplay.golang.org/ https://go2goplay.golang.org/p/mUWfsZPHs5h https://go2goplay.golang.org/p/mUWfsZPHs5h

avinassh 6y ago
Is it possible to compile my local Go code with generics?
- avery42 6y ago
  Yes, by building the dev.go2go branch: https://github.com/golang/go/blob/dev.go2go/README.go2go.md https://github.com/golang/go/blob/dev.go2go/README.go2go.md
hajile 6y ago
I'd kill for them adding support for structurally typed, non-nullable immutable tuples and records, destructuring, and pattern matching. This would make sharing data across channels much safer and seems like it could be implemented with minimal syntactic changes. I envision something like the following. //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 }
- andreygrehov 6y ago
  The Go team is extremely friendly, so I encourage anyone thinking they could improve the language to open a feature request on GitHub: https://github.com/golang/go/issues https://github.com/golang/go/issues
tbrock 6y ago
I love go but im annoyed they didn't choose angle brackets for the syntax. It's illogical to be annoyed at this, i know, but it feels like being different just for the sake of being different.
- thegeekpirate 6y ago
  > Angle brackets require unbounded parser look-ahead or type information in certain situations https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8 https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8
  - alblue 6y ago
    The argument seems to be that a,b=c<d,e>g could be misplaced based on whether this is a generic type or a pair of comparisons. 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.

avinassh 6y ago

Is it possible to compile my local Go code with generics?

avery42 6y ago
Yes, by building the dev.go2go branch: https://github.com/golang/go/blob/dev.go2go/README.go2go.md https://github.com/golang/go/blob/dev.go2go/README.go2go.md

hajile 6y ago

I'd kill for them adding support for structurally typed, non-nullable immutable tuples and records, destructuring, and pattern matching. This would make sharing data across channels much safer and seems like it could be implemented with minimal syntactic changes. I envision something like the following. //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 }

andreygrehov 6y ago
The Go team is extremely friendly, so I encourage anyone thinking they could improve the language to open a feature request on GitHub: https://github.com/golang/go/issues https://github.com/golang/go/issues

tbrock 6y ago

I love go but im annoyed they didn't choose angle brackets for the syntax. It's illogical to be annoyed at this, i know, but it feels like being different just for the sake of being different.

thegeekpirate 6y ago
> Angle brackets require unbounded parser look-ahead or type information in certain situations https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8 https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8
- alblue 6y ago
  The argument seems to be that a,b=c<d,e>g could be misplaced based on whether this is a generic type or a pair of comparisons. 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.