On Sunday, 15 November 2015 at 08:59:52 UTC, Ola Fosheim Grøstad wrote:
On Sunday, 15 November 2015 at 02:49:49 UTC, Jonathan M Davis wrote:
the program's data. Certainly, any immutable objects created at runtime are only protected from mutation by the type system.

That would be a bad assumption. It could be read only pages with MMU protection. (files, shared memory etc)

Well, that's news to me, but my understanding of stuff that low level isn't very good. Regardless, my point is that there's no guarantee that anything other than the type system protects immutable variables against mutation. For instance, this code compiles and runs just fine.

    void main()
    {
        auto i = new immutable int(5);
        assert(*i == 5);
        auto j = cast(int*)i;
        *j = 42;
        assert(*i == 42);
    }

And there's this bug about how non-shared static constructors routinely mutate immutable variables:

https://issues.dlang.org/show_bug.cgi?id=4923

So, while there _are_ cases where mutating immutable memory will cause a segfault, there is no guarantee that casting and mutating an immutable variable will cause any obvious problems at all.

So, allowing const to be cast away for the purposes of mutation becomes _very_ dangerous, because it's very easy to screw up and mutate immutable objects, and given how differently the compiler treats immutable objects (e.g. they're implicitly shared and allow for eliding function calls when used in conjunction with pure) on top of the guarantees that the compiler gives about immutable objects never mutating, the consequences of mutating an object variable are far worse than they are with mutating a mutable object being via a const reference, even when doing that via a cast is currently undefined behavior.

So, if we choose to put a backdoor in const, it would be far better to do so with something like @mutable than to treat casting away const from an object and mutating it as defined behavior - though I think that we should be _very_ sure that we're willing to pay the cost of that backdoor before we make that choice.

- Jonathan M Davis

Reply via email to