This seems to be very similar to a suggestion I made a couple of years ago:
https://gist.github.com/peter-mckenzie/5cc6530da1d966e743f4a39c150a6ac2
The spaces are in different places but that could be regarded as a matter
of style.
I always liked it, but maybe a little too quirky for most :-)
On Sunday, July 19, 2020 at 12:52:10 PM UTC+12, Laurens Hellemons wrote:
>
> 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 ren...@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 <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 golang-nuts...@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/83d65a60-26a6-43c7-b40a-87d50af39b3bo%40googlegroups.com.
