Go generics draft design: building a hashtable

Re:Go generics draft design: building a hashtable by monkeyfacebag on Wednesday June 17, 2020 @03:57PM (#23555990)

In my opinion, the new design doc clearly characterizes this as a design goal of the parser, rather than a hard constraint that cannot be resolved.

"Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple."

It's totally fair to question the tradeoff - should having a simple parser outweigh the potential ergonomic benefit of <>? I don't know. The forum for this is probably the golang-nuts group.

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by nemetroid on Wednesday June 17, 2020 @04:19PM (#23556231)

The design doc doesn't say "simple", it says "efficient".

I think "simpler" would have been a stronger argument. While using <> would make the parser more complex, I have a hard time seeing that making a meaningful performance difference in a compilation context. Maybe if you're parsing a lot of Go without actually compiling it, but that doesn't seem like a use case to optimize for.

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by mpoteat on Wednesday June 17, 2020 @04:02PM (#23556049)

It's all a matter of where you accept the complexity - in the compiler, in the language, or in the downstream applications. In my view it's an obvious choice to choose a more complicated compiler on exchange for simpler downstream applications...

[ Parent | on HN ]