Help me investigate a bug to file it.

Artur Skawina art.08.09 at gmail.com
Wed Jul 10 13:33:27 PDT 2013


On 07/10/13 21:36, monarch_dodra wrote:
> On Tuesday, 9 July 2013 at 00:06:11 UTC, Artur Skawina wrote:
>> That plus a non-existing this._input, results in a bit (too much)
>> magic, and the first test passes. The other one fails because of
>> the '$' (ie opDollar() call).
> In any case, it is now filed:
> http://d.puremagic.com/issues/show_bug.cgi?id=10597
> 
> I reduced it to this (imo) neat usecase:

> struct R
> {
>     void opIndex(int);
>     int opDollar();
> }
> R r;

> static assert(is(typeof(r[0]))); //ok
> static assert(is(typeof(r[$]))); //fails (!)

Yeah, I can't convince myself that it's ok for the /first/ assert
to pass - actually evaluating the "r[0]" expression in that same
context will *fail* (because 'r' isn't known at compile time).
It always possible to test with 'typeof(r.init[0])'.

The fact that

   static assert(__traits(compiles, r[0]));

succeeds, when that expression won't actually compile is also a
problem.

artur


More information about the Digitalmars-d-learn mailing list