I'd quite prefer [] over (). It would make F[t](v) distinct from F(x)(y) even if it's not distinct from m[x](y). On Thu, Sep 6, 2018 at 3:02 PM Ian Lance Taylor <i...@golang.org> wrote: > > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche <soapboxcic...@gmail.com> wrote: > > > > Wouldn't there be an issue with fp := AFunc[int] ? > > I don't think so. AFunc[int] would be parsed as an index operation, > and after name lookup it would resolve into either an array lookup or > a function instantiation, depending on the meaning of `int` in the > current scope. This is not very different from the way that t(v) > resolves to either a function call or a type conversion after name > lookup. It's quite different from using <>, which has to be parsed > quite differently depending on whether it is an instantiation or a > comparison. > > > > Though for that matter I wouldn't mind if the type part were repeated > > for instantiations like AFunc[type int] or even AFunc(type int) > > That would be possible but seems unnecessary. I personally would > prefer to avoid it. > > > > For that matter, always writing type would let you use < > since the > > parser could plausibly enter a separate mode when it hit the < token > > followed by type. > > > > Noisy but obvious at a glance what's happening. > > Yes, that is true except for the >> issue. > > 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. For more options, visit https://groups.google.com/d/optout.
