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#.
[ Parent
| on HN ]
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.