http://d.puremagic.com/issues/show_bug.cgi?id=199
--- Comment #31 from Stewart Gordon <[email protected]> 2013-05-30 16:13:24 PDT --- (In reply to comment #29) > I didn't advocate banning it. I advocate permanent deprecation, > because the semantics are bug prone, and we should (arguably) never > risk *silently* breaking working code. Your worry about this is out of all proportion, when you consider that: (a) All the examples that have so far been posted here are contrived. Somebody please show me some real-world code that only works as the programmer intended because of this "feature". Surely there's far more real-world code that _doesn't_ behave as the programmer intended because of this. (b) D isn't even an ISO (or ANSI or whatever) standard yet. As such, it's still a _good_ time to get all the potentially breaking changes out of the way. (c) D has in its time had some breaking changes that are much more serious than this. (d) Even long-standardised programming languages have had breaking changes in their time. C has had at least one breaking change in its time, though I don't know when this came in relation to its standardisation. C++11 introduces a change to how template instantiations are lexed, which can cause code to behave differently. > There is no reason to remove it for a long time, > possibly never. > >> The (imo correct) path is that the NoScopeStatment should still >> provide no scope, but emit a deprecated message if anything >> declared in the scope is used. If you're going to go as far as that, why not emit a deprecation message if any declarations appear in it at all? >> EG: >> >> void main() >> { >> label: >> { >> int i; >> } >> writeln(i); //(1) >> } >> >> (1) should emit a deprecation message. > > Sounds good. Can it be implemented easily? I can see that it would be complicated to get it right. The tiny risk of silently breaking any real-world code doesn't seem to justify it. As such, IMM, just fixing this issue and being done with it is the way to go. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
