On Tue, Jul 14, 2020 at 9:45 PM robert engels <reng...@ix.netcom.com> wrote: > > My opinion is that every major language (no flames please… lots of developers > write lots of programs and make money doing it) that supports generics uses < > > for generic types, so Go should too - since there is no reason to deviate > from this other than to avoid changes to the parser. Seems better to pay this > cost once - rather than every Go program that uses generics being harder to > read for eternity (especially for those readers that use a lot of languages).
Thanks for the note. I'll briefly mention, as others have, that Scala successfully uses square brackets for generics, and that in Go the map type already uses square brackets to indicate the generic key type (though the value type is outside the square brackets). So it's not like this is entirely new ground. It's also worth noting that the Go survey results (https://blog.golang.org/survey2019-results) show us that the languages most Go programmers are familiar with are Python and JavaScript, which of course do not use generics at all with any sort of brackets. So the familiarity argument only goes so far. More seriously, though, let's look closely at Robert's example: a, b = w < x, y > (z) When parsing this without any information about what the identifiers mean, this could be either an assignment of two values to two variables: a = w < x b = y > (z) or it could be a call of the instantiated function w<x, y> passing the argument z and returning two results. By the way, don't get distracted by the parentheses around z, it can be an arbitrary expression, so although (z) might be unusual using parentheses around a more complex expression might be entirely reasonable. Without knowing the type of w, we can not parse this statement. This has nothing to do with lookahead or the nature of parsing or anything else. It's fundamental to the syntax. In order for tools like gofmt and goimports to be effective and be fast enough to run on file save, they have to be able to parse Go code without knowing types. In the general case, where w might actually be written as pkg.w, knowing the type of w will require chasing through an arbitrary number of imported packages. Requiring simple tools like gofmt and goimports to do this kind of type checking would break one of the basic guidelines that Go has followed from the beginning: the language must be easy and fast to parse without knowing types. I'll note that C++ also has this syntactic problem, and indeed C++ cannot be parsed without full type information. This is part of why tools that work with Go code run much faster than tools that work with C++ code, and is part of why the Go compiler is much faster than typical C++ compilers. So it's really not a matter of "just fix the parser to use angle brackets." As far as I've been able to tell, using angle brackets is technically infeasible, given the way that Go works. Other languages make different choices, and those choices work for them, but this is not a choice that Go is able to make. So, I hear you: you and many others would prefer angle brackets. But unless and until someone explains how it could be done, we must continue to regard that choice as off the table. Sorry. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXJAXsPNQLp1Jwqp%2B_U95wQCXk_qdhK2MUQmhEyLUUWHQ%40mail.gmail.com.
