[generics] Replace () with <> or other character

[Charles Crete]

Based on the new proposal, having the type parameters as () seems very confusing, as now 3 things in a row use ():

- Type parameters

- Function parameters/arguments

- Return tuple

This results in code like (from the draft):

func Stringify(type T Stringer)(s []T) (ret []string) {
  for _, v := range s {
    ret = append(ret, v.String())
  }
  return ret
}

Instead, using <> similar to other languages, makes it easier to visual parse:

func Stringify<T Stringer>(s []T) (ret []string) {
  for _, v := range s {
    ret = append(ret, v.String())
  }
  return ret
}

This can also apply to type definitions:

type Vector<T> []T

To summarize:

- Having 3 times () in a row makes it confusing to visual parse

- The type keyword is not necessary

- Using <> would make it friendly (and easier to recognize)

[Denis Cheremisov]

makes it easier to visual parse

Are you sure? It may be a personal thing, but "visual parsing" of these <<< really annoys me, I would prefer `[]`, but I like `()` more than `<>`. In addition, a good IDE (not that well known overhyped editor on steroids) will highlight these fragments, so not really a problem.

среда, 17 июня 2020 г., 19:36:10 UTC+3 пользователь Charles Crete написал:

[Dimas Prawira]

more and more like Java.. 

BR

--
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/CALk%2Bt4a7a6G7komPB_N1ataYTOjKSU556Gp2cHge%2BxnYnoLBig%40mail.gmail.com.

[Ian Lance Taylor]

Let's try the current suggested syntax and see how it works out in practice.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java

Ian

[Nathanael Curin]

An argument for this is also that (all ?) languages that use generics use <>. It might make learning just easier for new Go developers that have experience from generics-compatible languages.

Dimas -> Resembling other languages in some ways is not necessarily a bad thing, if the idea behind it makes sense.

[Volker Dobler]

On Thursday, 18 June 2020 10:15:16 UTC+2, Nathanael Curin wrote:

An argument for this is also that (all ?) languages that use generics use <>. It might make learning just easier for new Go developers that have experience from generics-compatible languages.

And an argument  against using <> is that lots of languages with parametric polymorphism do not use <>. It makes learning just easier for new Go developers that have experience with such languages.

I dislike the use of () but a) this discussion can be made once the overall mechanism of generics / pp is settled and b) it really doesn't matter that much and c) it probably won't be plain <> anyway if its not () so endless repetitions of "<> please" is just a waste of time.

V.

[Brian Zhao]

Out of curiosity, would it be possible to have a workaround for the infinite lookahead problem? 

I happened to see a similar issue mentioned when implementing Swift Generics: https://github.com/apple/swift/blob/5bdc5ccd61cd43217e4f4e3515e32eb45e728df0/docs/Generics.rst#parsing-issues, and the proposed workaround was:

We're going to try a variant of #1, using a variation of the disambiguation rule used in C#. Essentially, when we see:
identifier <
we look ahead, trying to parse a type parameter list, until parsing the type parameter list fails or we find a closing '>'. We then look ahead an additional token to see if the closing '>' is followed by a '(', '.', or closing bracketing token (since types are most commonly followed by a constructor call or static member access). If parsing the type parameter list succeeds, and the closing angle bracket is followed by a '(', '.', or closing bracket token, then the '<...>' sequence is parsed as a generic parameter list; otherwise, the '<' is parsed as an operator.

Would something similar work in go's parser? I'm personally in favor of the <> syntax, since it's very similar to other languages (C++, Swift, Rust, Java, C#).

Thanks!

--
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/CAOyqgcU%2B8XFLa7LU1Eaq_bYziAdBLxnR_WG19LLfcoN4qMh-ew%40mail.gmail.com.

[Jesper Louis Andersen]

On Thu, Jun 18, 2020 at 6:38 PM Brian Zhao <bzsp...@gmail.com> wrote:

Would something similar work in go's parser? I'm personally in favor of the <> syntax, since it's very similar to other languages (C++, Swift, Rust, Java, C#).

It is just another parameter. I wouldn't give it special syntactical treatment. That a parameter varies by type rather than term is just a small curio.. See the lambda cube.

[Sam Mortimer]

On Wednesday, June 17, 2020 at 5:50:24 PM UTC-7, Ian Lance Taylor wrote:

On Wed, Jun 17, 2020 at 9:36 AM Charles Crete <cha...@cretezy.com> wrote:
>
> Based on the new proposal, having the type parameters as () seems very confusing, as now 3 things in a row use ():
> - Type parameters
> - Function parameters/arguments
> - Return tuple

[cut]

Let's try the current suggested syntax and see how it works out in practice.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java

Ian

I agree with others that multiple () blocks on the same line is hard to read (so far, at least).  In general, I think parser complexity should come second to the cognitive complexity of humans reading code.  Any other means of separating type parameters in a more visually distinctive way would seem preferable.

Regards,

-Sam.

[Denis Cheremisov]

Not all languages use <> for parametric parametrism. I tried lots of variants and my favorite is [] from Scala (I don't like Scala, BTW).

четверг, 18 июня 2020 г., 11:15:16 UTC+3 пользователь Nathanael Curin написал:

[Backend Ninja]

I agree

[Ian Lance Taylor]

On Wed, Jun 17, 2020 at 10:52 PM Brian Zhao <bzsp...@gmail.com> wrote:
>
> Out of curiosity, would it be possible to have a workaround for the infinite lookahead problem?
>
> I happened to see a similar issue mentioned when implementing Swift Generics: https://github.com/apple/swift/blob/5bdc5ccd61cd43217e4f4e3515e32eb45e728df0/docs/Generics.rst#parsing-issues, and the proposed workaround was:
>
>> We're going to try a variant of #1, using a variation of the disambiguation rule used in C#. Essentially, when we see:
>> identifier <
>> we look ahead, trying to parse a type parameter list, until parsing the type parameter list fails or we find a closing '>'. We then look ahead an additional token to see if the closing '>' is followed by a '(', '.', or closing bracketing token (since types are most commonly followed by a constructor call or static member access). If parsing the type parameter list succeeds, and the closing angle bracket is followed by a '(', '.', or closing bracket token, then the '<...>' sequence is parsed as a generic parameter list; otherwise, the '<' is parsed as an operator.
>
>
> Would something similar work in go's parser? I'm personally in favor of the <> syntax, since it's very similar to other languages (C++, Swift, Rust, Java, C#).

It may be possible to do something like that in a Go parser. But as
you can see it's complicated and hard to specify. And let's not
forget about the >> issue when you write List<List<int>>, the issue
being that >> is the right shift operator. For many years C++
programmers had to write List<List<int> >, and the fix for that syntax
tweak was really complex. (But I don't know how Swift does it.)

Let's be clear: we may well change the syntax to stop using
parentheses for type lists. But we aren't going to simply switch to
angle brackets. That has too many complications.

Ian