http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #10 from bearophile_hugs@eml.cc 2010-08-08 12:05:25 PDT ---
With -O -unittest DMD is already able to catch the first of the two shown cases
(it doesn't catch the case with __traits(compiles, a.x = 5).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #11 from bearophile_hugs@eml.cc 2010-09-21 04:45:47 PDT ---
See also bug 4906

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4595


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com
            Summary|Accessing non-static member |[tdpl] Accessing non-static
                   |of a null reference         |member of a null reference
                   |compiles                    |compiles


--- Comment #12 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-12-18 20:20:09 PST ---
Failing unittest in TDPL:

unittest
{
  class A { int x; }
  A a;
  assert(!__traits(compiles, a.x = 5));
}

Such programs must be statically rejected, guaranteed if there's no intervening flow in between definition and first use. We can work on improving that later, but for now let's get the obvious case out of the way.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #13 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-17 12:54:33 PDT ---
(In reply to comment #12)
> Failing unittest in TDPL:
> 
> unittest
> {
>   class A { int x; }
>   A a;
>   assert(!__traits(compiles, a.x = 5));
> }
> 
> Such programs must be statically rejected, guaranteed if there's no intervening flow in between definition and first use. We can work on improving that later, but for now let's get the obvious case out of the way.

After a few years of D use, I actually find the above will create problems. We often use traits like these to check whether something is compilable, even if the object is left uninitialized.

For example if you want to check whether method "foo" of object "c" is callable with an int type:

static assert(__traits(compiles, c.foo(1)));

Making this fail now because of flow analysis could hurt code that does unittesting.

I think a runtime exception is sufficient right now, and the OP feature could be part of some specialized flow-analysis tool.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #14 from Kenji Hara <k.hara.pg@gmail.com> 2013-09-19 00:33:55 PDT ---
(In reply to comment #13)
> After a few years of D use, I actually find the above will create problems. We often use traits like these to check whether something is compilable, even if the object is left uninitialized.

Today, code flow analysis for class ctor call (super(...) and this(...))
behaves as follows.

class Foo
{
    this(int) {}
}

class Bar : Foo
{
    this()
    {
        static assert(is(typeof(super(0))));
        static if (is(typeof(super(0)))) {}
        // inside typeof(), code flow analysis never works.

        super(1);
        // OK

        static assert(is(typeof(super(0))));
        static if (is(typeof(super(0)))) {}
        // also OK

        super(2);
        // Error: multiple constructor call
    }
    this(int)
    {
        static assert( __traits(compiles, super(1)));
        // inside __traits(compiles), code flow analysis is enabled.

        super(1);
        // Error: multiple constructor call

        static assert(!__traits(compiles, super(2)));
        // The _second_ super call makes error.

        super(3);
        // Error: multiple constructor call
    }
}

This is expected behavior, from my compiler-internal knowledge.

- `is(typeof(exp))` tests that the exp has valid type or not. For type
calculation, the code flow analysis and its validation result is just
unnecessary.

- `__traits(compiles, exp)` tests the exact validness of `exp` at there. In other words, `__traits(compiles)` converts the error occurrence on the `exp` semantic analysis to the compile-time boolean value. In there, code flow analysis is enabled, and the errors will be counted normally.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #15 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-19 03:52:35 PDT ---
(In reply to comment #14)
> - `is(typeof(exp))` tests that the exp has valid type or not. For type
> calculation, the code flow analysis and its validation result is just
> unnecessary.
> 
> - `__traits(compiles, exp)` tests the exact validness of `exp` at there. In other words, `__traits(compiles)` converts the error occurrence on the `exp` semantic analysis to the compile-time boolean value. In there, code flow analysis is enabled, and the errors will be counted normally.

Well that explains why sometimes is(typeof()) works where __traits(compiles)
doesn't.

But as far as I know none of this is properly documented, and it's probably why people file bugs when a difference in behavior is found.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------