http://d.puremagic.com/issues/show_bug.cgi?id=9397
--- Comment #5 from S�nke Ludwig <[email protected]> 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: -------
