dmd 2.063 beta 5

[Artur Skawina]

On 05/23/13 18:26, Steven Schveighoffer wrote:
> On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina <art.08.09 at gmail.com> wrote:
> 
>> If it wasn't clear - it is about the _language_, not what some compiler
>> currently happens to do. Being able to mutate /initialized/ immutables
>> is a bad idea. IOW you should not be able to modify 'Packet.type' above.
> 
> The immutable isn't initialized.  The memory it happens to be using before initialization happens to have the '7' bit pattern in it.
> 
> Once it is initialized, I agree it should be immutable from that point on.

It's all about the definition. Again, I'll point out that the code that we're
talking about here *can not* exist right now - until now the compiler has not
allowed mutation. So this is about a /change/ to the language, and isn't really
related to fixing that implicit-static bug - it's just that once that change
is made it then becomes possible to support the in-ctor re-initialization
of immutable fields. Which isn't really all that useful, but carries a cost.


>> Keep in mind that modifying Packet.type is illegal /right now/. Even from
>> a ctor or static-ctor. This does not need to change when such fields are
>> no longer always implicitly static. While allowing re-initialization
>> of immutables from a ctor is possible, it does not really give you much,
>> while weakening const. (eg by making CT evaluation of such fields impossible).
> 
> That's an issue of where Packet.type lives.  It doesn't live inside an instance right now, in the new version it does.
> 
> If Packet.type is not given an initializer, it's inside the instance and it (correctly IMO) can be modified inside a ctor until it is used.
> 
> These rules are perfectly consistent.
> 
> I don't see how they make CT evaluation impossible.

The old way meant that the value was statically known and could be accessed at CT.
Allowing ctors to modify the fields means that the compiler can not make any
assumptions about the value. [1] Which affects CT and constant folding/propagation
etc. For example you couldn't then do this:

struct Packet(uint TY) { /*...*/immutable uint type=TY; immutable ubyte len=PLen(TY); /*...*/ }
auto PProcess(PT)(PT* p) { static if (p.type<128) if (p.type==42) sendp(p, p.len*4); }

Even w/o the static-if it would be much less efficient. Yes, there are other
ways to achieve a similar effect, but they are significantly more complicated.

The most conservative approach is to initially disallow mutation from ctors - this
restriction can always be lifted later and doing so does not affect any existing
program.
Treating 'const' differently from 'immutable' is also a possibility, and could
be a future option.

Then there's the issue of 'immutable one=1;' being very misleading; it certainly
would be misinterpreted often enough (by assuming that ODR applies here).


artur

[1] BTW, I'm wondering if these changes also affect module-level const/immutable
    members... No DMD here to test, though.