RfC for language feature: rvalue struct

[Paul Backus]

On Wednesday, 25 January 2023 at 17:47:34 UTC, FeepingCreature 
wrote:
> 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.)

I agree that if we could start with non-refrenceability as the 
default and make referenceability opt-in, that would be a cleaner 
design than D's referenceability-by-default.  Unfortunately, that 
option is not on the table, at least not for D.

For D, the options actually available to us are "implement 
`rvalue struct` as an opt-in special case" or "don't do that." I 
remain unconvinced that the former is better language design than 
the latter.

(Another way to put this is that "returning one tiny part of the 
language to simplicity and sanity" is worse than leaving the 
whole language *consistently* "insane.")