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

           Summary: Regression(2.059): typeof(this) incorrect in mixin
                    template
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: thecybershadow@gmail.com


--- Comment #0 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-03-15 17:05:19 PDT ---
template IsValid(T)
{
    enum IsValid = is(typeof(T.init.x));
}


mixin template T()
{
    static assert(IsValid!(typeof(this)));
}

struct S
{
    int x;
    mixin T;
}

The IsValid template is not necessary to reproduce the problem - it's for illustration.

This also fails:
    static assert(is(typeof(typeof(this).init.x)));
But not this:
    static assert(is(typeof(x)));

-- 
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=7717


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2012-03-16 01:36:31 PDT ---
It's not clear that there's a bug here. typeof(this).init correctly shouldn't compile inside a mixin, because the mixin might add an extra field -- so then init would change.

.init is defined only when all possible members of the aggregate have been declared.

Can you come up with a valid example?

-- 
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=7717


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch


--- Comment #2 from timon.gehr@gmx.ch 2012-03-16 03:08:17 PDT ---
(In reply to comment #1)
> It's not clear that there's a bug here. typeof(this).init correctly shouldn't compile inside a mixin, because the mixin might add an extra field

It does not add an extra field.

> -- so then init would change.

If I added some random character to a valid d program, then it would likely not be valid anymore. What does this prove?

> 
> .init is defined only when all possible members of the aggregate have been declared.

This is the case in the example. What should be illegal is adding a field that changes .init based on a static condition that depends on .init. This would be part of a necessary general overhaul of symbol lookup works in DMD: Forward declarations and compile-time reflection make it possible to write contradictory or ambiguous D programs. The compiler should detect such setups in the least conservative way we can come up with.

-- 
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=7717



--- Comment #3 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-03-16 08:44:28 PDT ---
If this behavior is invalid by design, then the error message should be improved (e.g. to ".init not known at this point" or "recursive semantic analysis attempt on S").

The workaround is to use std.traits.hasMember (which, underneath, uses
__traits(allMembers, T)).

-- 
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=7717



--- Comment #4 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-03-16 09:03:39 PDT ---
> then the error message should be improved

Never mind, the check is inside an is() condition - so AFAIU any errors should
be silenced.

-- 
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=7717



--- Comment #5 from Don <clugdbug@yahoo.com.au> 2012-03-16 23:47:01 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > It's not clear that there's a bug here. typeof(this).init correctly shouldn't compile inside a mixin, because the mixin might add an extra field
> 
> It does not add an extra field.
> 
> > -- so then init would change.
> 
> If I added some random character to a valid d program, then it would likely not be valid anymore. What does this prove?

The point is that accessing .init from inside a mixin is not valid in the
general case. Although in this specific example, it could be made to work, that
isn't true in general.
Likewise, .sizeof is not defined until all declarations have been run.

> > .init is defined only when all possible members of the aggregate have been declared.
> 
> This is the case in the example. What should be illegal is adding a field that changes .init based on a static condition that depends on .init. This would be part of a necessary general overhaul of symbol lookup works in DMD: Forward declarations and compile-time reflection make it possible to write contradictory or ambiguous D programs. The compiler should detect such setups in the least conservative way we can come up with.

OK. That's clearly an enhancement request. Compiler is working as designed. This only seemed to compile before, because of a compiler bug.

-- 
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=7717



--- Comment #6 from Don <clugdbug@yahoo.com.au> 2012-04-02 04:54:08 PDT ---
The change in behaviour is probaby related to the fixes for bug 3509 and bug 3510.

-- 
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=7717


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com
           Severity|regression                  |enhancement


-- 
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=7717


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #7 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-12 20:22:27 PST ---
Status in 2.061:

The OP sample works, however:

> This also fails:
>     static assert(is(typeof(typeof(this).init.x)));
> But not this:
>     static assert(is(typeof(x)));

Both of these fail now.

-- 
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=7717


Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


--- Comment #8 from Vladimir Panteleev <thecybershadow@gmail.com> 2013-01-13 06:37:26 EET ---
(In reply to comment #7)
> Both of these fail now.

Those assert lines should be placed instead of the assert line in the example code.

All of the cases presented seem to work in DMD 2.061.

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