This is similar to C++ template, and it's very clear to understand.
On Wednesday, July 15, 2020 at 1:06:24 PM UTC+8, Paul Johnston wrote:
>
> 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/31376715-50f1-450f-b8ad-12f02fbc05d2o%40googlegroups.com.
