[Issue 19621] The specification is self-contradictory on immutability

[d-bugmail at puremagic.com]

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

Neia Neutuladh <dhasenan at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec
           Priority|P1                          |P3
             Status|NEW                         |RESOLVED
                 CC|                            |dhasenan at gmail.com
         Resolution|---                         |WONTFIX
           Severity|major                       |minor

--- Comment #1 from Neia Neutuladh <dhasenan at gmail.com> ---
Making it defined behavior would forbid memoizing based on reference equality
and sharing immutable data between threads. It might mean that string constants
must be copied on program startup so they're not in read-only memory. It would
mean that immutable means no more than const.

This would be a major change requiring a DIP, and it would certainly be
rejected.

Now. In order to make it *not* be undefined behavior to cast something to
immutable while other mutable references exist to that data, and *only* be
undefined behavior to write to that data, you'd have to increase the scope of
"what behavior is potentially undefined" to every time you write to memory that
might have more than one reference to it. For instance:

---
void doSomething(ubyte[]);

auto buf = new ubyte[512];
doSomething(buf);
buf[0] = 1;
---

Should that be potentially undefined behavior? That's what we would have to do
in order to make things more consistent between those to aspects of the spec,
and that really should be well-defined behavior.

By making only the cast to immutable potentially undefined, and then writing to
something cast from immutable undefined, the total amount of undefined behavior
is reasonably limited.

--