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 fu
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 ->
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
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
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 t
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
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 is
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 u
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 mod
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
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
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
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 wo
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 diffe
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(
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
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
17 matches
Mail list logo
