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


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-25 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: -------

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


--- Comment #1 from Sönke Ludwig <sludwig@outerproduct.org> 2013-02-08 00:56:44 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: -------

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



--- Comment #2 from Sönke Ludwig <sludwig@outerproduct.org> 2013-02-08 01:01:58 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: -------

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


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

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


--- Comment #3 from Don <clugdbug@yahoo.com.au> 2013-02-08 02:50:50 PST ---
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: -------

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



--- Comment #4 from Don <clugdbug@yahoo.com.au> 2013-02-08 02:56:07 PST ---
"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: -------

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



--- Comment #5 from Sönke Ludwig <sludwig@outerproduct.org> 2013-02-08 03:22:26 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: -------