Whilst I could live with square brackets, I prefer round brackets too and still would do even if angle brackets were available.
This is because when I see different types of brackets following an identifier, I (and probably many others) tend to associate them as follows: 1. square brackets -> arrays/slices/maps 2. curly brackets -> function bodies, struct/interface declarations 3. angle brackets -> ordering operators 4. round brackets -> function declarations, function invocations, type conversions, grouping stuff together So I agree with rog that #4 best fits the existing Go ethos. On Friday, September 7, 2018 at 12:47:59 PM UTC+1, rog wrote: > > 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....@gmail.com > <javascript:>> wrote: > > Bikesheding mode on... > > > > On Fri, Sep 7, 2018, 00:06 jimmy frasche <soapbo...@gmail.com > <javascript:>> 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 <ia...@golang.org > <javascript:>> wrote: > >> > > >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche <soapbo...@gmail.com > <javascript:>> > >> > 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...@googlegroups.com <javascript:>. > >> 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...@googlegroups.com <javascript:>. > > 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.
