www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7717] New: Regression(2.059): typeof(this) incorrect in mixin template

reply d-bugmail puremagic.com writes:
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



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: -------
Mar 15 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7717


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Mar 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7717


timon.gehr gmx.ch changed:

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




 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: -------
Mar 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7717




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: -------
Mar 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7717




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: -------
Mar 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7717






 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: -------
Mar 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7717




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: -------
Apr 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jan 12 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7717


Vladimir Panteleev <thecybershadow gmail.com> changed:

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



06:37:26 EET ---

 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: -------
Jan 12 2013