Generics: More on parens

[Aaron Cannon]

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 all the hard work!

Aaron

--
This message was sent from a mobile device

[Ian Lance Taylor]

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

[Aaron Cannon]

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

[Jon Conradt]

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

[David Anderson]

Here's one reason to not do that (screenshot from gmail, in a chrome with a ton of unicode-ready fonts, displaying your email) :

Also already addressed at https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use .

- 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...@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.

[Nigel Tao]

Heh, I also run GMail+Chrome, but I see rectangles instead of blank spaces (see attachment), which only reinforces your point.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMx%2Br7XuXpbXeRXPedh6x8FF0UoNLmiEkTTRBS40MN6DyUFZDw%40mail.gmail.com.

[David Riley]

On Jun 18, 2020, at 6:19 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?

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