When you refer to beginners, I think you mean developers from other languages (Java/C#/C++...) that already know the concept of generics. I don't think they will have problems adapting to a square brackets notation... they are smart people, and after all they have to learn many other syntactical differences as well, so one more difference is not going to be the deal breaker. And if they make <mistakes>, the compiler will [surely] tell them ;-)
In fact, the square bracket notation is already adopted for declaring the type of maps and slices. So switching to angle brackets will make Go's generics implementation internally inconsistent, since you must declare a map[string]int with angle brackets and then elsewhere, you will be using <int> for the same concept. I think it is much more important that Go remains internally consistent in its use of angle brackets. Best, :) Hein On Wednesday, July 15, 2020 at 7:03:40 PM UTC+2 dmar...@gmail.com wrote: > On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels 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). >> > > This really captures my feeling perfectly, the parser changes have to be > less man hours to build and maintain going forward than the man hours of > all the existing and new developers. All options have a downsides at least > <T> is as "standard" as one can get when talking about generics. > > Some version of <T> will help beginners in reducing the cognitive load > when learning and using Go. > > Thanks, > -Dan > > > > >> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor <ia...@golang.org> >> wrote: >> > >> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W. <oneo...@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 golan...@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/c2c831e5-cdd3-4602-901f-53f927b2ab12n%40googlegroups.com.
