Helping with __mutable (which will be renamed to __metadata)

[Timon Gehr]

On 15.04.19 19:24, Suleyman wrote:
> On Monday, 15 April 2019 at 15:59:35 UTC, Timon Gehr wrote:
>> At that point, why do you need to slap `immutable` on your type in the 
>> first place? Why does your proposed semantics make any sense for 
>> reference counting or caching/lazy evaluation?
> 
> Otherwise the sole protection from being stored in readonly memory

This is not true and it is not even the right way to think about it. The 
language semantics is distinct from how it is implemented in a compiler. 
The reason why data with __mutable fields cannot be put in readonly 
memory is because crash on write is not acceptable behavior. It does not 
even need to be explicitly specified.

> is not enough incentive for adding a keyword feature

The cost of adding a __keyword is pretty close to zero. And anyway, 
that's a superficial syntactic concern, not even really worth debating 
over at this point, as a) the current version of the DIP gets the 
semantics wrong and b) the necessary changes to the language 
specification are of similar size whether you add a __keyword or a 
pragma. (And whether or not you add a tiny bit more type checking is 
independent of the annotation syntax.)

> if this is the only contribution beyond an unsafe cast

This is not what's being proposed. There are unsafe operations and there 
are invalid operations. The DIP's aim is to make some cases unsafe that 
were previously invalid. (And if you have to implement an annotation for 
fields anyway, adding the handful lines of frontend code that avoid 
additional casts, which are a blunt instrument that can hide what would 
otherwise be type errors, e.g. during a refactoring, does not seem bad 
enough to me to not even be counted as a contribution.)

> then a compiler directive should suffice such as pragma(noROM) or similar.
A pragma is sufficient (but not required) anyway, but noROM is a 
terrible name.