Here's one reason to not do that (screenshot from gmail, in a chrome with a ton of unicode-ready fonts, displaying your email) : [image: lol.png] Also already addressed at https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use .
- Dave On Thu, Jun 18, 2020 at 3:20 PM Jon Conradt <j...@theconradts.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/5e32c71c-43f5-494e-9de6-ba96bce00e8en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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%2Br7XuXpbXeRXPedh6x8FF0UoNLmiEkTTRBS40MN6DyUFZDw%40mail.gmail.com.
