On Thu, 23 May 2013 05:05:01 -0400, Don <turnyourkidsintoc...@nospam.com>
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.
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.
I disagree.
struct S
{
const int x;
}
S s1; // x is 0
S s2 = S(5); // x is 5
Adding an initializer simply changes the default value from 0 to whatever
you want. It's quite consistent IMO.
The issue you are having is that the old behavior that you rely on is
inconsistent. I agree that this is a large problem, especially if you
have code like you wrote, which likely expects to set y and not x!
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.
Module constructors are totally inconsistent with struct/class
constructors, and have been for some time. One doesn't "call" a module
constructor, it's implicitly called. The semantics are totally
different. It also makes no sense to set a value to something different,
because there isn't more than one instance of the module. It will be set
to one value and that's it.
I think the only possible solution is to make it an error to provide a
const or immutable member with an initializer.
This would be my recommendation:
1. Make the above an error. It is not good to allow code with changed
semantics to silently compile without intervention.
2. Disable the error with a switch (to allow for the new behavior).
3. In a future release, remove the error.
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.
I can see uses. If you don't want x.init to be the default for x, then
you need to set it to something else.
For example:
struct Widget
{
immutable string name = "(unset)"; // instead of ""
}
-Steve
