Personally, I'm happy with the choice to use round brackets. Go started down this road a long time ago, in my view, by making type conversions look like function calls.
When `typename(x)` is qualitatively different from `value(x)`, I think it's quite reasonable that `x(typename)` is qualitatively different from `x(value)` too. In other words, I think it's nicely regular and fits Go's aesthetic well. On 7 September 2018 at 09:05, Sebastien Binet <seb.bi...@gmail.com> wrote: > Bikesheding mode on... > > On Fri, Sep 7, 2018, 00:06 jimmy frasche <soapboxcic...@gmail.com> wrote: >> >> 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). > > > One could add a dot, like for type checking: > F.[T](y) > > Yet another rule to learn... :) > > -s > > >> 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. > > -- > 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. -- 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.
