Re: [go-nuts] Generics: More on parens
On Jun 18, 2020, at 6:19 PM, Jon Conradt 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? The biggest reason, IMO: those are difficult to type on a keyboard. What you're proposing here will be nearly impossible to type on any editor that doesn't have specialized support, which is a lot of them. The keystrokes you propose (shift-opt-0/9) are Mac specific, since no one else has an Option key, and on my Terminal (on OS X) they result in the characters "·" and "‚" respectively, so I can't use them in vi. The second-biggest reason is that they aren't guaranteed to display right everywhere (especially on screen readers, and I know we have a number of visually-impaired folks on this list for whom this is vitally important). With apologies to those who can't view images, here is how this looks on my mail client in both proportional font (as received) and monospaced (as typed): This will cause problems. The authors of the proposal explicitly said they couldn't bring themselves to use something that's not ASCII, and I think that's still a valid decision. - Dave -- 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/B2D47B12-F91B-4F87-8E20-33ACE5B35878%40gmail.com.
Re: [go-nuts] Generics: More on parens
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 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 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.)
>>>
>>> x2 := []T.{} 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 wrote:
>>> > On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
>>> > 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 .>> >> Print(string)(stringSlice) we would do Print.(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
>>
>> .
>>
> --
> 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
>
Re: [go-nuts] Generics: More on parens
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 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.)
>>
>> x2 := []T.{} 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 wrote:
>> > On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
>> > 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 .> >> Print(string)(stringSlice) we would do Print.(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
>
> .
>
--
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.
Re: [go-nuts] Generics: More on parens
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.)
>
> x2 := []T.{} 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 wrote:
> > On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
> > 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 . >> Print(string)(stringSlice) we would do Print.(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.
Re: [go-nuts] Generics: More on parens
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.)
x2 := []T.{} 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 wrote:
> On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
> 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 .> Print(string)(stringSlice) we would do Print.(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/CAERFoOjiW_uBz9jaOgT6wLN%3D_BMqp_hOAoSwsGdiSRbW%3DB%3DFNw%40mail.gmail.com.
Re: [go-nuts] Generics: More on parens
On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon 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 . Print.(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/CAOyqgcXO2KhFng7ern7%2BQ%3Dsus%2BKA0Rjz4V__zkCiTZYjM27LTg%40mail.gmail.com.
