RfC for language feature: rvalue struct

[Tim]

On Wednesday, 25 January 2023 at 16:23:51 UTC, FeepingCreature 
wrote:
> D libraries like to behave like they can declare variables and 
> assign values to them. (Oh, to live in such innocence!) This is 
> all over Phobos, Dub, etc. `immutable struct` frustrates this 
> belief. Because you could always take the address of a field, 
> which would be `immutable T*`, you could see the value changing 
> when you overwrite the variable - a constness violation. 
> `immutable` solves this by preventing you from modifying the 
> memory of the field while the pointer lives. This largely 
> doesn't work, because people don't test with `immutable struct` 
> in the first place. If an `rvalue struct` is used, the naive 
> code works as before, but the type gets the correctness 
> benefits of immutable: you can only construct a new value 
> through the constructor.

Maybe escape analysis could be used as an alternative. If the 
compiler can prove that no pointer to a local variable or its 
members could escape, then it should be safe to reassign to the 
variable. With DIP1000 the compiler should be able to determine 
this.