If the generic expression <T> was always attached/constrained to the "type"
or "func" keyword (rather than the type or function name), perhaps this
would decrease the lookahead problems with lexing? For example:
*type<T> Point struct {*
* x, y int*
* data T*
*}*
*type<R,S> Transformer interface {*
* Transform(R) S*
*}*
*func<T> Stringify(s []T) string {*
*}*
*type<T> Vector []T*
On Tuesday, July 14, 2020 at 10:45:41 PM UTC-6 [email protected] 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 <[email protected]> wrote:
> >
> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W. <[email protected]>
> 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 [email protected].
> > 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e2459352-ab61-4bba-99a3-215496faaab5n%40googlegroups.com.
