Bug 9397 – Size error with struct with ctor and self-typed nested enum

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.

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

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.

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

"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.

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)

*** Issue 12665 has been marked as a duplicate of this issue. ***

How come the size calculation can't be delayed until that enum value is actually needed? There's no recursive dependencies here, so I think this should juts work.

> 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. I agree with this. A valid fix which would not qualify as being labeled a regression would be to forbid adding fields after the size has already been queried, i.e. allow such code if the enums occur at the end of the struct.

(In reply to Vladimir Panteleev from comment #7) > There's no recursive dependencies here, so I think this > should juts work. Or even more sensibly, first build the layout of the struct and then do the semantic analysis of enums, methods, etc.

*** This issue has been marked as a duplicate of issue 6766 ***