On Wed, Jun 17, 2020 at 10:52 PM Brian Zhao <bzspar...@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
> On Wed, Jun 17, 2020 at 5:50 PM Ian Lance Taylor <i...@golang.org> wrote:
>>
>> On Wed, Jun 17, 2020 at 9:36 AM Charles Crete <char...@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
>> >
>> > 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)
>>
>> 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
>>
>> --
>> 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/CAOyqgcU%2B8XFLa7LU1Eaq_bYziAdBLxnR_WG19LLfcoN4qMh-ew%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/CAOyqgcW%2BCOAe-yK%2B%3D3HO%3Dp%3DBBWoqhtvq0H%2BMSobHpkCh_nLO3g%40mail.gmail.com.
