dmd 2.063 beta 5

[Don]

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 
>> <art.08.09 at gmail.com> 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.