News for hackers. Stuff that matters.
Re:Go generics draft design: building a hashtable by Sharlin on Wednesday June 17, 2020 @04:25PM (#23556293)
C++ and Rust require extra disambiguating syntax in some contexts (C++ the `foo.template bar<T>()` syntax, Rust the "superfish operator" `foo.bar::<T>()`. Java works around the problem by awkwardly putting the generic argument list in front of the method name (`foo.<T>bar()`). I don't know about C#.
Re:Go generics draft design: building a hashtable by DougBTX on Wednesday June 17, 2020 @04:35PM (#23556415)
C# is `foo.bar<T>()`, I’m not sure what compromises that had to make for that to work but from an end-user perspective it works well.
Re:Go generics draft design: building a hashtable by oxnrtr on Friday June 19, 2020 @01:39AM (#23571331)
They parse it one way, and if they figure out the other parse option was right, they go back and fix the parse tree.

Basically, unlimited look-ahead.

Re:Go generics draft design: building a hashtable by lostmsu on Sunday June 21, 2020 @03:15AM (#23590436)
Is it somehow a problem?
Re:Go generics draft design: building a hashtable by steveklabnik on Wednesday June 17, 2020 @05:59PM (#23557277)
(teeny tiny note: turbofish, not superfish)
Re:Go generics draft design: building a hashtable by Sharlin on Wednesday June 17, 2020 @06:45PM (#23557701)
Oops :D
Re:Go generics draft design: building a hashtable by oxnrtr on Friday June 19, 2020 @01:40AM (#23571339)
Using [] is the optimal choice for languages in general, but they can't even use that because they blew away that syntax for indexing.
Re:Go generics draft design: building a hashtable by Sharlin on Saturday June 20, 2020 @08:13AM (#23583507)
Scala uses [] for generics and () for indexing, which sort of makes sense given that in the end arrays are just functions.
Re:Go generics draft design: building a hashtable by lostmsu on Sunday June 21, 2020 @03:16AM (#23590438)
So are the uninstantiated generic types ;-)