Tagging onto this point: while Go deviates from other languages in a number of important ways, syntax at the level of things like parens, brackets, etc is not one of these key differences. It is almost entirely consistent with the "de facto" C-style choices in this respect (to the extent that people mistakenly regard it as just a subset of C). In this context, it does seem a bit of "being different for its own sake", to adopt something *other* than the < > convention for generic types.
Yes, Go should boldly Go where no language has gone before^*, but when it is basically adopting a well-established paradigm widely used in existing languages, doesn't it also make sense to adopt the well-established syntax associated with that paradigm? (although the proposed Go generics differ in some important ways from other languages, the use of type parameters is not one of them.) While we've been asked to focus on the more "objective" facts of parsing considerations here, the above logic would suggest a different approach: if there is any way to adopt the established conventional syntax and make the parsing work, then that is what should be done. So, essentially, this puts the onus back on the parser programmers to definitively *rule out* the use of < > -- is it really that difficult / costly to do a bit of look-ahead and disambiguate the different use cases? - Randy * e.g., see https://github.com/golang/go/issues/39669 for a more radical departure from convention, doing away with the extra parens entirely. > On 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). > >> On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor <i...@golang.org> wrote: >> >> On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W. <oneof...@gmail.com> >> wrote: >>> >>> This feels a little better, but honestly I'm still all for angle brackets >>> or like Watson suggested, guillamets. >>> >>> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 >>> fn[T1](fn2[T2](fn3[T3](v))) // 2 >>> fn<T1>(fn2<T2>(fn3<T3>(v))) // 3 >>> fn«T1»(fn2«T2»(fn3«T3»v))) // 4 >>> >>> To me, with a background in C++ and Typescript and a little bit of Rust, #3 >>> and #4 are just natural and easier to read. >> >> The advantage of parentheses is that the language already uses >> parentheses for lists in various places. Of course that is also the >> disadvantage. >> >> When considering something other than parentheses, I encourage people >> to look for objective reasons why one syntax is better than another. >> It's going to be different from other aspects of the language. So >> what reason would we have for preferring one syntax over another? >> >> For example: >> >> Robert already gave reasons why square brackets are better than angle >> brackets. >> >> The disadvantage of guillemets is that they are hard to type on many >> keyboards. So to me either square brackets or angle brackets would be >> better than guillemets. >> >> The disadvantage of a two character sequence such as <: :> is that it >> is more typing. So again either square brackets or angle brackets >> seem to me to be better. >> >> An example of a reason that square brackets might be a poor choice >> would be ambiguous parsing, or cases where the code is harder to read. >> >> It's true that some other languages use angle brackets, but Go already >> does many things differently. That is only a minor advantage for >> angle brackets. To me at least it does not outweigh the >> disadvantages. >> >> In short, please try to provide reasons for a different syntax. "It >> looks good" is a valid reason, but please try to explain why it looks >> better than square brackets or parentheses. >> >> Thanks. >> >> 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/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%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/825D82DD-C595-415D-B0C6-7BE090A015C7%40ix.netcom.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/2793272E-F287-42F7-8DCE-843797EC344B%40gmail.com.
