Field initializers shared between instances

[ntrel]

I think I saw that opend had a solution to disallow using an array literal to initialize a field unless opted into with a special attribute. I can't find anything about that now, the changes.html page doesn't seem to list that.

Does it also disallow = new Class and any other reference expression that is problematic?

I just came across Timon's bug that shows this problem can mutate immutable data:
https://issues.dlang.org/show_bug.cgi?id=10376

[adamdruppe]

Yeah, it disallows any reference to mutable data. (and yeah I'm behind on updating the website so a lot of stuff pending me getting that typed up) So like:

struct A {
        //@(imported!"core.attribute".mutableRefInit)
        Object o = new Object; // this is an error. note = null; is still allowed though
}

Is an error. You can uncomment that attribute to silence the error if you know better. It tries to descend into structs and static arrays to allow references so long as they are copied by value. So this is still illegal:

struct B {
        Object o;
}

struct A {
        B b = B(new Object);
}

But this should work and currently doesn't:

struct B {
        immutable Object o;
}

struct A {
        B b = B(new immutable Object); // rejects this otherwise valid code
}

(i have a fix for this pending i just got distracted playing with safe by default)

However many cases do work even as-written.

struct B {
        void function() fp;
}

struct A {
        B b = B();
}

That, for example, didn't work in the first draft, but does now. A function pointer itself is mutable, but since it is copied by-value along with struct B and the function it points to is presumed immutable (cuz it is pointing to code and mutating code is only done when you cast it or whatever; the D type system doesn't consider that a thing) this will be permitted.

So we have like i think a 90% solution right now and a little more work should get the rest of the way. That said, I'd rather have rejects-valid than accepts-invalid here; worst case with a false positive, you tell the stupid compiler to shut up with the annotation, vs a false-negative being surprising and/or incorrect behavior at runtime.

Anyway, the relevant code is here:

https://github.com/opendlang/opend/blob/master/compiler/src/dmd/initsem.d#L122

It already detected a legit bug in my dom.d that I unintentionally wrote and never hit just out of luck!

[ntrel]

   //@(imported!"core.attribute".mutableRefInit)

When using that attribute, I think the field should become @system because it allows violating immutable, at least if there is an immutable instance of the aggregate created as well as a mutable one.

   Object o = new Object; // this is an error. note = null; is still allowed though

I've been doing some testing and the detection seems to work well. It's great it allows tail const fields.

It already detected a legit bug in my dom.d that I unintentionally wrote and never hit just out of luck!

Great!

[adamdruppe]

When using that attribute, I think the field should become @System because it allows violating immutable,

yeah that seems fair.