[go-nuts] Why can't we use < > for the Go generic parameters ?
I know about the problems it raised with C++, but Go is different. Go2 draft restricts generic parameters to types. The only case where there might eventually be an ambiguity is with specialized functions in expressions. I would like to determine if it's still possible to use < > and avoid the pitfalls. One of the option to consider is to use a special character to signal the specializing of a generic. Such a special character could be $ for instance. A generic type or function would be instantiated by the following expression : foo$(...) bar$(...) foo2$>(...) When there is only one generic parameter, we could use a concise form foo$int(...) == foo$(...) foo2$List$float(...) == foo2$>(...) My current understanding is that the $ would remove ambiguity in parsing. The reason I would prefer to use < > is to - satisfy to rule of least surprise. - readability -- 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
On Thu, Sep 6, 2018 at 9:49 AM Christophe Meessen <
christophe.mees...@gmail.com> wrote:
func f(bool) { ... }
func g() { f(ad) }
an similar constructs require unlimited look ahead to distinguish the above
example from something generics. The current Go parser can always decide
where to go based on just the next symbol.
--
-j
--
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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
I understand your example, but it wouldn't be a problem anymore with a special
character like a $ sign. D use the !.
--
Bien cordialement,
Ch.Meessen
> Le 6 sept. 2018 à 09:56, Jan Mercl <0xj...@gmail.com> a écrit :
>
> On Thu, Sep 6, 2018 at 9:49 AM Christophe Meessen
> wrote:
>
> func f(bool) { ... }
>
> func g() { f(ad) }
>
> an similar constructs require unlimited look ahead to distinguish the above
> example from something generics. The current Go parser can always decide
> where to go based on just the next symbol.
>
> --
> -j
--
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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe Meessen: > > I understand your example, but it wouldn't be a problem anymore with a > special character like a $ sign. D use the !. > Scala uses [ and ] instead of < and > to avoid the problem that < and > mean something different depending on the context. -- 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
On Thu, Sep 6, 2018 at 12:49 AM, Christophe Meessen wrote: > > I know about the problems it raised with C++, but Go is different. Go2 draft > restricts generic parameters to types. > The only case where there might eventually be an ambiguity is with > specialized functions in expressions. > > I would like to determine if it's still possible to use < > and avoid the > pitfalls. > > One of the option to consider is to use a special character to signal the > specializing of a generic. Such a special character could be $ for instance. > > A generic type or function would be instantiated by the following expression > : > > foo$(...) > bar$(...) > foo2$>(...) > > When there is only one generic parameter, we could use a concise form > > foo$int(...) == foo$(...) > foo2$List$float(...) == foo2$>(...) > > My current understanding is that the $ would remove ambiguity in parsing. Thanks. I agree that that your suggestion work. It just boils down to aesthetic preference. > The reason I would prefer to use < > is to > - satisfy to rule of least surprise. Your suggested syntax is not the same as any existing language I know of, so I don't think it's reasonable to claim that it is unsurprising. > - readability One of the goals of Go is to look light on the page. Personally I don't think scattering $ around the code looks good. I think it is less readable. But, as I say, this is an aesthetic preference. If there is a consensus in favor of your syntax, or some other unambiguous syntax, I'm OK with that. 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
On Thu, Sep 6, 2018 at 5:28 AM, wrote: > > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe Meessen: >> >> I understand your example, but it wouldn't be a problem anymore with a >> special character like a $ sign. D use the !. > > > Scala uses [ and ] instead of < and > to avoid the problem that < and > mean > something different depending on the context. Note that simple [ and ] don't work in Go, as explained in the generics design draft. 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
But we can still using [type T] instead. On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 5:28 AM, > wrote: > > > > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe > Meessen: > >> > >> I understand your example, but it wouldn't be a problem anymore with a > >> special character like a $ sign. D use the !. > > > > > > Scala uses [ and ] instead of < and > to avoid the problem that < and > > mean > > something different depending on the context. > > Note that simple [ and ] don't work in Go, as explained in the > generics design draft. > > 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
On Thu, Sep 6, 2018 at 1:38 PM, xingtao zhao wrote: > > But we can still using [type T] instead. That is a very good point. Thanks. As far as I can see we could plausibly switch to square brackets if we prefer them. Ian > On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote: >> >> On Thu, Sep 6, 2018 at 5:28 AM, wrote: >> > >> > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe >> > Meessen: >> >> >> >> I understand your example, but it wouldn't be a problem anymore with a >> >> special character like a $ sign. D use the !. >> > >> > >> > Scala uses [ and ] instead of < and > to avoid the problem that < and > >> > mean >> > something different depending on the context. >> >> Note that simple [ and ] don't work in Go, as explained in the >> generics design draft. >> >> 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
Wouldn't there be an issue with fp := AFunc[int] ? 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) 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. On Thu, Sep 6, 2018 at 1:43 PM Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 1:38 PM, xingtao zhao wrote: > > > > But we can still using [type T] instead. > > That is a very good point. Thanks. As far as I can see we could > plausibly switch to square brackets if we prefer them. > > Ian > > > > > On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote: > >> > >> On Thu, Sep 6, 2018 at 5:28 AM, wrote: > >> > > >> > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe > >> > Meessen: > >> >> > >> >> I understand your example, but it wouldn't be a problem anymore with a > >> >> special character like a $ sign. D use the !. > >> > > >> > > >> > Scala uses [ and ] instead of < and > to avoid the problem that < and > > >> > mean > >> > something different depending on the context. > >> > >> Note that simple [ and ] don't work in Go, as explained in the > >> generics design draft. > >> > >> 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
On Thu, Sep 6, 2018, 23:03 jimmy frasche wrote: > Wouldn't there be an issue with fp := AFunc[int] ? > > 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) > > 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. > The parser does not and not easily can know if 'a' in ' -- -j -- 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
I meant that if the instantiation syntax is T. Though it'd probably have to treat a >> token as two separate > in declarations which is annoying. On Thu, Sep 6, 2018 at 2:07 PM Jan Mercl <0xj...@gmail.com> wrote: > > > > On Thu, Sep 6, 2018, 23:03 jimmy frasche wrote: >> >> Wouldn't there be an issue with fp := AFunc[int] ? >> >> 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) >> >> 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. > > > The parser does not and not easily can know if 'a' in ' type name. > > -- > > -j -- 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
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 wrote: > > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
Bikesheding mode on... On Fri, Sep 7, 2018, 00:06 jimmy frasche 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 wrote: > > > > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche > 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
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 wrote: > Bikesheding mode on... > > On Fri, Sep 7, 2018, 00:06 jimmy frasche 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 wrote: >> > >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche >> > 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
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 > wrote: > > Bikesheding mode on... > > > > On Fri, Sep 7, 2018, 00:06 jimmy frasche > 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 > wrote: > >> > > >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche > > >> > 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
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 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 wrote: >> > Bikesheding mode on... >> > >> > On Fri, Sep 7, 2018, 00:06 jimmy frasche 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 >> wrote: >> >> > >> >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche >> > >> > 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.
