On Friday, 24 May 2013 at 10:55:09 UTC, Artur Skawina wrote:
On 05/24/13 02:33, Steven Schveighoffer wrote:
On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina
<[email protected]> wrote:
On 05/23/13 23:06, Steven Schveighoffer wrote:
compiles:
struct S
{
const int x;
this(int n)
{
x = n;
}
}
It's the 'const int x = 42;' case we're talking about. *That*
one does not
compile and doesn't need to. It /could/, but I see no reason
to allow this;
My example is essentially:
const int x = 0;
No, that's not the same.
const int w;
is the same syntax used in C++. It's a declaration without an
initializer. It signals your intention to initialize it later.
Now, D does default-initialize everything, so that there really
isn't any such thing as an uninitialized variable in D, but it
still signals the intention that you will modify it later.
int is a misleading example since the default initializer is 0,
and it's common for people to rely on that.
Better to use char or float, or a class, where the default
initializer is not usable, and it's clearer that it's a bug to
use it.
The only way I can understand this feature is that it is changing
the meaning of initializers inside aggregates.
Previously, they were initializers. Now, they're not. They're
setting the value of .init for the class.
And they use the same syntax which is used for actual
initializers.
In the past, the compiler didn't check if you from set a field in
a constructor, which you had already initialized with an
initializer.
But, it didn't really matter.
With a const field, it makes a much bigger difference, since if
an initializer was specified, the only way that the field can
make sense is if you modify it somewhere else. So the initializer
MUST be able to be overwritten.
This has lead us to this oddity that under the new regime,
const char c = 'e';
is setting the value of c, unless it is inside an aggregate, in
which case it's not initializing c, it's just specifying what
.init is for that struct.
So, it's overloading the syntax to mean two very different things.
---
Hence, you are arguing for a change in behavior. And the
arguments for that
are extremely weak. The goal should be to allow const
initialization to happen
exactly once.
I agree. This is the crux of the argument.
Are you and I the the only ones who see that as a valuable
property of the language? I'm astonished that others are so
willing to sacrifice it.
