Re:Go generics draft design: building a hashtable
by IshKebab on Thursday June 18, 2020 @05:31AM
(#23561399)
I'd definitely prefer angle brackets. With everything being parantheses I just get lost keeping track of what is what - they're now used for type parameters, parameters and return values, one after the other with no separation, and two of them are optional. Quite confusing if you ask me.
Re:Go generics draft design: building a hashtable
by Cthulhu_ on Thursday June 18, 2020 @08:47AM
(#23562563)
And yet, if you think about parsing it, they're all ways to group things together. Avoiding adding reserved characters (see also the discussion about adding ternaries) is a worthy goal to pursue. Keeps the parser(s) simpler too.
An IDE / coloring scheme can help make things look more distinct if need be.
Re:Go generics draft design: building a hashtable
by tapirl on Wednesday June 17, 2020 @09:19PM
(#23558785)
Comparing it with the builtin hashtable:
* the custom one: hashtable.Table(string, int)
* the builtin one: map[string]int
The syntax forms are quite different. Wouldn't it be better to make them consistent? Is it so hard to achieve this?
Re:Go generics draft design: building a hashtable
by jeremyjh on Wednesday June 17, 2020 @09:43PM
(#23558915)
It would not surprise me to learn that the parser has special rules for the token "map".
Re:Go generics draft design: building a hashtable
by tapirl on Wednesday June 17, 2020 @10:13PM
(#23559107)
Yes, the fact that "map" is a keyword and "Table" is not really makes a trouble for parser. But I think we should think towards the road. There should be always a solution.
Re:Go generics draft design: building a hashtable
by mpfundstein on Thursday June 18, 2020 @04:53AM
(#23561152)
lisp
It seems powerful enough to cover most cases of generics. Architecture astronauts will never be happy, but tough.