I think this should be no error?
void main()
{
uint[10] arr1;
ulong idx = 3;
//uint[] arr2 = arr1[ idx .. idx + 3 ]; // Error if with compiler switch -w
uint[] arr3 = arr1[ cast(int)(idx) .. (cast(int) idx) + 3 ]; // OK
uint[] arr4 = arr1[ cast(int) idx .. cast(int) idx + 3 ]; // OK
uint[] arr5 = arr1[ cast(int)(idx) .. cast(int)(idx) + 3 ]; // C style cast illegal, use cast(idx)+3
uint[] arr6 = arr1[ cast(int)(idx) .. cast(int)(idx + 3) ]; // OK
}
Comment #1 by bugzilla — 2006-03-11T13:34:00Z
(idx)+3 can be parsed as a C-style cast: (idx)(+3). These are marked as illegal in order to catch errors in transliterating C code into D code.
This is deliberate behavior, not a bug.
Comment #2 by smjg — 2006-03-15T09:39:53Z
(In reply to comment #1)
> (idx)+3 can be parsed as a C-style cast: (idx)(+3).
Not by any compliant D code parser.
The spec doesn't allow
cast(int)(idx) + 3
to be parsed as anything but an AddExpression. Indeed, I thought the whole point of removing the old syntax was to remove the ambiguity from the grammar. It also specifically states
D introduces the cast keyword:
cast(foo) -p; // cast (-p) to type foo
(foo) - p; // subtract p from foo
> These are marked as illegal
> in order to catch errors in transliterating C code into D code.
Even if the parser is fixed to match the spec, it will still throw an error during semantic analysis if idx turns out to be a type, which is the only situation in which it is necessary to catch the error.
An error message tailored to this special case is nice, but not necessary. But if you still want it....
Does the compiler still remember that idx was in brackets when it's time to do semantic analysis? If so, you could still do it by looking out for the form
( Type ) + ...
and similarly for -, ~ and *.