Comment #0 by bearophile_hugs — 2011-07-30T06:56:07Z
I think this D2 code shows an error:
import std.stdio;
void main() {
writeln(typeid(typeof(string[].init)));
writeln(typeid(typeof(string[][].init)));
writeln(typeid(typeof(string[][][].init)));
writeln(typeid(typeof((string[]).init)));
}
Output, DMD 2.054:
immutable(char)[]
immutable(char)[]
immutable(char)[]
immutable(char)[][]
Comment #1 by kennytm — 2011-07-30T08:44:22Z
Apparently DMD shouldn't accept string[].init at all, e.g. int[].init is a parser error:
--------------------------
alias int[] F;
//enum f = int[].init; // error (as expected)
enum g = F[].init; // no error, return 'null' of type F.
--------------------------
Comment #2 by bearophile_hugs — 2011-07-30T09:13:40Z
(In reply to comment #1)
> Apparently DMD shouldn't accept string[].init at all, e.g. int[].init is a
> parser error:
Isn't it better to modify DMD to accept both string[].init and int[].init, and return the correct results in both cases?
Because the alternative idiom to create an empty array is to use cast(int[])[], and it's better to avoid casts where possible.
Comment #3 by kennytm — 2011-07-30T12:03:14Z
(In reply to comment #2)
> (In reply to comment #1)
> > Apparently DMD shouldn't accept string[].init at all, e.g. int[].init is a
> > parser error:
>
> Isn't it better to modify DMD to accept both string[].init and int[].init, and
> return the correct results in both cases?
>
> Because the alternative idiom to create an empty array is to use cast(int[])[],
> and it's better to avoid casts where possible.
You could also just add a pair of parenthesis:
(string[]).init
(int[]).init
And (X[]).init returns 'null', not '[]'.
I'm not sure about allowing `S[].prop`. If this is allowed, we should also allow `S[3].prop` and `S[T].prop` and maybe even `S*.prop`. Maybe let's have a rejects-valid or enhancement request.
Comment #4 by bearophile_hugs — 2011-07-30T12:37:31Z
(In reply to comment #3)
> You could also just add a pair of parenthesis:
>
> (string[]).init
> (int[]).init
This was my last example.
> I'm not sure about allowing `S[].prop`. If this is allowed, we should also
> allow `S[3].prop` and `S[T].prop` and maybe even `S*.prop`. Maybe let's have a
> rejects-valid or enhancement request.
Beside returning the correctly typed value, as alternative I accept this:
string[].init
to produce a syntax error that suggests the programmer to use (string[]).init instead. What I don't accept it silently returning a value of the "wrong" type.
Comment #5 by kennytm — 2011-07-30T13:41:25Z
(In reply to comment #4)
> (In reply to comment #3)
>
> > You could also just add a pair of parenthesis:
> >
> > (string[]).init
> > (int[]).init
>
> This was my last example.
>
Right.
> > I'm not sure about allowing `S[].prop`. If this is allowed, we should also
> > allow `S[3].prop` and `S[T].prop` and maybe even `S*.prop`. Maybe let's have a
> > rejects-valid or enhancement request.
>
> Beside returning the correctly typed value, as alternative I accept this:
>
> string[].init
>
> to produce a syntax error that suggests the programmer to use (string[]).init
> instead. What I don't accept it silently returning a value of the "wrong" type.
I agree.
Comment #7 by bearophile_hugs — 2013-01-16T09:58:21Z
(In reply to comment #6)
> I'm not sure T* can be done like this, but it also produces an error instead of
> being ignored silently.
Thank you.
In the unittests have you added a test case that shows such error message?
Comment #8 by yebblies — 2013-01-16T16:35:14Z
(In reply to comment #7)
> (In reply to comment #6)
>
> > I'm not sure T* can be done like this, but it also produces an error instead of
> > being ignored silently.
>
> Thank you.
> In the unittests have you added a test case that shows such error message?
For:
auto x = string*.init;
You get:
testx.d(3): Error: undefined identifier 'init'
Because it is parsed as (string) * (.init). To me it is much more clear that string*.init is invalid code compared to string[].init.
Comment #9 by github-bugzilla — 2013-01-20T23:00:22Z