It's covered in the generics design doc, and by about a dozen threads on golang-nuts at this point. Unless the parsing issues can be addressed satisfactorily, that option is off the table right now. Same for [T] and other variations.
- Dave On Sat, Jun 20, 2020 at 10:34 AM <cnye...@gmail.com> wrote: > Hi, > > The type parameters in the current proposal uses `(type xxx)` which is > visually hard to distinguish from function parameters. > > There are reasons stated in the proposal to not adopt <> (which is common > in other languages) which I'm not going to challenge. But have you > considered `(<T>)`? It should eliminate the infinite lookahead concern of > using <>, require minimal change to the existing implementation in go2go, > and IMO improves the readability of Go code w/ generics. > > -- > 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/8c23b598-5b67-4ca3-a736-ea18fa4060e8o%40googlegroups.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/CAMx%2Br7Uh5E79JCBER24SYrQjHGKTtncd%3D9tbAiFESVVc_qQ2bg%40mail.gmail.com.
