Helping with __mutable (which will be renamed to __metadata)

[Timon Gehr]

On 15.04.19 18:37, 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?
> 
> I don't know but immutability has been breached for sure

No. It's like saying Haskell does not support immutable data because the 
only way to implement lazy evaluation on the machine is using mutation. 
(Or even worse, to claim that D does not support immutability because 
the garbage collector can reclaim memory that was previously typed 
immutable.)

I think D needs to be able to implement its own runtime library and 
manual memory allocation schemes without compiler magic unavailable to 
user programs.

> and hiding that with @system doesn't help

Nothing is being hidden.

> I would say disallowing __mutable inside 
> immutable objects  makes more sense

Regarding sense: I have yet to find any in your "concealing" argument. I 
have tried and wasted too much time now.

> than just concealing the crime with @system
@system means you are not protected against writing programs that do not 
have defined semantics. Seems like a good enough fit.

> unless someone has a safe solution.

No, that makes no sense at all. The only simple enough safe solution is 
to turn all __metadata use cases into compiler magic one-by-one. And you 
win nothing. The simplest way to implement that is to just add 
__metadata and simply add a compiler check that ensures user code cannot 
access it.