The more I think about this suggestion, the more I like it.
- It solves the lookahead problem (I think);
- it visually separates the type parameters from the actual parameters and
return types, so the choice of delimiter characters for the type arguments
becomes less relevant from a readability standpoint;
it even makes sense *semantically*, since what you're defining with a
generic type/func is really *multiple* types/funcs (a family of related
ones), so it makes sense for the definition to look like an
array/list/vector.
I haven't played with this style yet, so I'm not sure that it doesn't
present other drawbacks, but this is my favorite proposed syntax so far.
On Wednesday, July 15, 2020 at 7:06:24 AM UTC+2 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/3eae208c-0272-4fe8-a071-539f205eb936n%40googlegroups.com.
