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! 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/CABrbJR6xB%3DhaQ%2BFHX28QyhKQwrHBnJqRnZ6Mb6xma%3D3_XAbVKA%40mail.gmail.com.
