RfC for language feature: rvalue struct

[FeepingCreature]

On Monday, 30 January 2023 at 13:53:53 UTC, Dukc 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.
>
> Isn't this what private/`@system` (DIP1035) fields with 
> public/`@trusted` getter functions are for?

Yes, the behavior of "private fields with public getters" is 
exactly what we're aiming for. (`@system` - not really; we're not 
interested in doing un `@safe` things to them. This is purely 
about functional programming style.)

Having an in-language way to declare "immutable rvalue 
everything" would pose some advantages over getters though:

- we wouldn't have to figure out when we'd need to dup a field on 
access to avoid mutation-at-a-distance: sSince immutable is 
transitive, the answer is "never", which also makes the GC happy
- we avoid the template overhead of having to generate accessors 
for every field, with all the required analysis to figure out 
attributes etc.
- even struct methods cannot mutate fields, for maximum purity
- it just looks nicer.