I agree with Alan and I actually think the parentheses-based syntax is fine. In Go as it is now, there is no case where using brackets on a variable results in a call to code somewhere else in the project. It's always some kind of indexing operation. Parenthesis have a history of doing this with function calls. If we adopt the bracket syntax for generics, it may become a bit harder when reading code to see which lines call out to another part of the project and which lines don't. This is often a problem with languages that support properties and operator overloading. I appreciate Go's clarity in this matter and I think the bracket syntax might undermine it a bit.
On Fri, Sep 7, 2018 at 6:31 AM <alan.f...@gmail.com> wrote: > 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> wrote: >> > Bikesheding mode on... >> > >> > On Fri, Sep 7, 2018, 00:06 jimmy frasche <soapbo...@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 <ia...@golang.org> >> wrote: >> >> > >> >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche <soapbo...@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...@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...@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.
