www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9397] New: Size error with struct with ctor and self-typed nested enum

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9397

           Summary: Size error with struct with ctor and self-typed nested
                    enum
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com



18:53:53 PST ---
struct S
{
    this(int i) { }
    int i;
    enum s = S(0);  // L5: fail
}

void main() { }

Error: cannot create a struct until its size is determined

This used to be a wrong-code bug (see Issue 8741), but now it's an error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 25 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9397


Sönke Ludwig <sludwig outerproduct.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sludwig outerproduct.org
           Severity|normal                      |regression



PST ---
Setting to regression, as it works up to v2.061.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9397




PST ---
Let me rephrase that. Before this triggered an error, the example worked fine
because the constructor call is equivalent to using a struct literal. This
special case has allowed me to work around the various issues surrounding
self-typed constants. Now with this error all hope for a workaround seems lost.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9397


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|regression                  |normal



This isn't a regression. It has never worked.
(Silently generating wrong code doesn't count as working).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9397




"This special case has allowed me to work around the various issues surrounding
self-typed constants"

s/special case/compiler bug/

You should be specific about what the "various issues" are, and then close this
bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9397




PST ---
While writing an answer I noticed that this can be easily worked around by
changing the code to (add an explicit type to the enum):

struct S
{
    this(int i) { this.i = i; }
    int i;
    enum S s = S(0);
}

So since I'm now looking at changing a few dozen lines of code to workaround
this instead of hundreds or more, and also unglifying the code, this has become
much less critical for me personally.

Regarding the other bugs in this area, there have been some, including
http://d.puremagic.com/issues/show_bug.cgi?id=1800 and some partially related,
such as http://d.puremagic.com/issues/show_bug.cgi?id=3801. I didn't find
anything that is still open, though. The comment was more about the history of
the code construct that is shown here.

---

Regarding normal vs. regression, you can also view it this way: The code above
is valid and did the right thing, even if just by accident. If the code later
does not compile anymore that may not be a regression from a compiler-internal
view, but from the outside it is. (I won't argue about this now that there is a
workaround, but thats my view on it)

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