Regarding the parsing: as I suggested in my email, but perhaps was unclear, in case of two conflicting *purely syntactic* interpretations (without using any type information), you could just choose the more high-frequency interpretation (i.e., type parameters) and force the programmer to use additional parens if they actually want the other interpretation.
So in the case of the example, w < x, y > (z) is *automatically, syntactically* interpreted as a function call using 2 type parameters, and if you want it to be two different relational expressions, you have to wrap them in parens: (w < x), (y > (z)) This latter use is likely to be vanishingly rare (someone could run their code analysis on it), so this seems like a small inconvenience. Maybe there are other such conflicts? If this is the only one, I don't think it is sufficient to rule out the use of < >. My mention of the point about gofmt was just that it should get rid of the seemingly redundant extra paren around (z), but I just tried it and apparently it does not, even with gofmt -s. Anyway, the above point stands: you CAN parse < > correctly by just making purely syntactic choices in the case of conflicts, and this applies to all Go tools using the same purely syntactic parsing pass. Also, according to Tiobe, Scala is ranked 39, and whereas C, Java, C++, C#, are all top 10, and the C family is clearly the syntactic heritage of Go. And the use of [ ] in map is more semantically associated with its conventional use as an element accessor in arrays / slices, not with some more general kind of type parameter. - Randy > On Jul 15, 2020, at 11:48 AM, Ian Lance Taylor <i...@golang.org> wrote: > > 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. -- 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/FE09C8A9-99AF-494A-AED2-327410C23EA4%40gmail.com.
