Heh, I also run GMail+Chrome, but I see rectangles instead of blank spaces (see attachment), which only reinforces your point.
On Fri, Jun 19, 2020 at 8:28 AM David Anderson <d...@natulte.net> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/CAMx%2Br7XuXpbXeRXPedh6x8FF0UoNLmiEkTTRBS40MN6DyUFZDw%40mail.gmail.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/CAOeFMNU1vp14WxwYo_Pt0mceTHBZiAyjaTA1BQNfNRAwEGbArA%40mail.gmail.com.
