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 <i...@golang.org> wrote:
> On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
> <cann...@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/CAERFoOjiW_uBz9jaOgT6wLN%3D_BMqp_hOAoSwsGdiSRbW%3DB%3DFNw%40mail.gmail.com.
