RfC for language feature: rvalue struct

[FeepingCreature]

On Wednesday, 25 January 2023 at 17:28:10 UTC, Paul Backus wrote:
> On Wednesday, 25 January 2023 at 16:23:51 UTC, FeepingCreature 
> wrote:
>> Before I take on the effort of writing up and submitting a 
>> DIP, let me solicit feedback and see if anyone can see a 
>> reason why this idea is dumb and doesn't work.
>>
>> tl;dr: `immutable struct` was a mistake: it's too weak. 
>> `rvalue struct` is what we really want.
>>
>> [...]
>
> I agree that `immutable struct` is a mistake. It's a weird 
> special case in the language, and because of that most D code 
> is not prepared to deal with it.
>
> I am not convinced that the solution to this is to introduce a 
> new language feature that is even weirder and specialer.

I mean, I think this is the problem. The only thing about `rvalue 
struct` that is "weird" and "special" is that it isn't the 
default. D opts you in, without your consent or asking, to a huge 
amount of language power when it comes to manipulating values. If 
you declare a variable, you can assign it, reassign it, take its 
address, access fields, take the address of arbitrary 
subfields... That works fine in a language like C, that 
deliberately makes no guarantees about anything, and if we want 
to go that way we may as well remove `private` and go back to 
monke. But D2 tries to have its cake and eat it too, to let you 
make code safe and predictable, while *still* opting you into 
mutability and referenceability and thus actually making some 
tasks straight up impossible (without heavy casting).

`rvalue` is not a unique and special snowflake, but an attempt to 
return one tiny part of the language to simplicity and sanity. 
(If it were up to me, every struct and every variable would be 
`rvalue` unless you explicitly declared it otherwise.)