This is what I was thinking. Format for the common case. At compile/link time you would be able to figure out the conflict and throw an error and the dev could add the parens to make it unambiguous.
> On Jul 15, 2020, at 4:36 PM, Randall O'Reilly <rcoreil...@gmail.com> wrote: > > 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/F4492612-1A47-4F30-9A7C-164C97A97383%40ix.netcom.com.
