Generics for Go

Posted Jul 7, 2020 20:49 UTC (Tue) by NYKevin (subscriber, #129325)
Parent article: Generics for Go

> When parsing code within a function, such as v := F<T>, at the point of seeing the < it's ambiguous whether we are seeing a type instantiation or an expression using the < operator. Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser efficient.

Eh... Python used square brackets to solve this exact problem (which had the bonus of being entirely backwards-compatible with their existing syntax; Python's types are "just" variables pointing to class objects, so applying the subscript operator was already syntactically legal). Perhaps Go didn't want to parse generics as an extension/generalization of the subscript operator? I suppose that saves you the trouble of disambiguating generics from "classical" subscripting at the semantics layer, but you're already going to have to do kind-checking there anyway (i.e. to prohibit Int<List> and similar errors), so additionally checking that the argument *is* a type isn't really that much more work.

Maybe they just thought that parentheses were less ugly than square brackets?

Generics for Go

Posted Jul 8, 2020 13:41 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> but you're already going to have to do kind-checking there anyway (i.e. to prohibit Int<List> and similar errors), so additionally checking that the argument *is* a type isn't really that much more work.

But you don't want your AST module to have to decide that. It feels like a layering violation to me.

Generics for Go

Posted Jul 9, 2020 17:10 UTC (Thu) by renox (guest, #23785) [Link]

I wonder why everyone just doesn't copy DLang solution: using !( ) for generics: no ambiguity, no need to hack the parser, no conflict with with arrays.