Ian, I like the direction being taken on Generics, and I am thankful the Go Team did not rush into an implementation.
I'm not a huge fan of another set of ()'s and I agree with not wanting the overhead of overloading <>. That got me thinking that we are in the 21st century. We all use editors which are comfortable with Unicode. Why not take advantage of characters beyond 7-bit ASCII? http://xahlee.info/comp/unicode_matching_brackets.html I kind of like the 'fuzzy' nature of ⧙ and ⧘, but to try this out we would need some investment from the Go Team. func Print⧙type T⧘(s []T) { for _, v := range s { fmt.Print(v) } } My experience with Generics is that you primarily author generic code when you are building libraries, and as a developer you don't do that as often as you use libraries. There is a cost to learning the new keystroke (option-shift-9 and option-shift-0 in a properly configured editor). Jon On Wednesday, June 17, 2020 at 7:25:36 AM UTC-7 Aaron Cannon wrote: > Thanks Ian for the reply. > > I certainly understand wanting to get more experience with the > proposed syntax, but I still don't think the trade-offs are worth it. > In particular, I remain concerned about the cognitive load of using > parens in yet another context, and the (IMHO) unnecessary breaking of > backwards compatibility, even if only in very few cases. > > Moving away from parens to something like what I proposed would, I > believe, remove all the ambiguities identified in the proposal. var f > func(x(T)) would become the unambiguous var f func(x.<T>) > > x2 := []T.<v2>{} as opposed to needing yet another set of parens. > > And so on for the other parsing ambiguities mentioned in the proposal. > > To be clear, I don't think it has to be the syntax I propose, but I do > think it should be easily recognizable as unique by the parser and > humans alike. > > The reason I favor the <> syntax is that <> is well known from C++ > (and maybe other languages?) as denoting something dealing with > generics. I also like the .<> for instantiation because it resembles > type assertion .(). Type assertion is essentially collapsing a broader > type to a narrower type, which is sort of what type instantiation is > doing if you squint a bit. :) > > Anyway, just my $0.02. Thanks again for all the hard work on this. > > Aaron > > On 6/16/20, Ian Lance Taylor <ia...@golang.org> wrote: > > On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon > > <can...@fireantproductions.com> wrote: > >> > >> I, like many others, am not fond of all the parenthesis, particularly at > >> call sites. I think at definition sites, it's not so bad. It seems like > >> the only objection to < and > are the complexity it adds for parsing. It > >> also seems like the only place it adds ambiguity is at call or > >> enstantiation sites. So what if we used .<? E.G. instead of > >> Print(string)(stringSlice) we would do Print.<string>(stringSlice) I > think > >> definitions could just swap () for < > for generic type parameters, > >> without the dot. > >> Aside from that, and wishing that the proposal specified that generics > >> would all be resolved at compile time rather than at run time, I'm > really > >> loving this! > > > > Thanks for the note. I think we should get some experience with > > writing code using this syntax before we discard it. > > > > 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/5e32c71c-43f5-494e-9de6-ba96bce00e8en%40googlegroups.com.
