On 05/23/13 11:05, Don wrote: > On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote: >> >> Join the dmd beta mailing list to keep up with the betas. This one is pretty >> much good to go, unless something disastrous crops up. >> >> http://ftp.digitalmars.com/dmd2beta.zip >> >> Remaining regressions: >> >> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED > > NO NO NO NO. I am violently opposed to this release. > > This beta contains the worst language misfeature of all time. It's silently > snuck in under the guise of a bugfix.
It is a bugfix. It's also a breaking change, for code that relied on the buggy behavior. There may be ways to ease the migration. But it's not a 'misfeature'. The language changes with /every/ frontend release, often silently or with just a note in some bugzilla entry.. This case isn't any worse and at least this change is actually a real fix. The scoped import change, which makes local imports effectively 'public' is a much more serious problem. Undoing that one would be painful in the future, if it were to stay. ( http://d.puremagic.com/issues/show_bug.cgi?id=10128 ) > struct S > { > const int x = 7; > int y; > } > > In previous releases, S.x was always 7. > But now, if you write > > S s = S(5); > > then x gets changed to 5. > This means that the const variable x has been initialized TWICE! > > This new behaviour is counter-intuitive and introduces a horrible > inconsistency. Yes, this is wrong and just shouldn't be allowed. And, yes, even inside ctors. > This is totally different to what happens with module constructors (you get a > compile error if you try to set a const global if it already has an > initializer). Likewise, everywhere else in the language, when you see a const > variable with an initializer, the initializer gives its value. Yes, introducing a "const and initialized, but still mutable" class makes no sense. > I think the only possible solution is to make it an error to provide a const > or immutable member with an initializer. Except for the issue mentioned above, the new behavior is right. Adding a keyword ("static") to such declarations should not be a real problem. AIUI the compiler can be made to list all the places which need changing. But, yes, the fact that the old (buggy) code compiles, but now silently drops that implicit "static" isn't ideal. Would making 'struct S{const a=1;}" illegal for a release really be a significant improvement? Any code not updated during that 'migration' period would then still be in the same situation... > If you are providing an initializer, you surely meant to make it 'static > const', and that is certainly true of all existing usages of it. > As far as I can tell, this new feature exists only to create bugs. No use > cases for it have been given. I cannot imagine a case where using this > feature would not be a bug. struct Packet(uint TYPE) { immutable uint type = TYPE; // ... } artur
