RfC for language feature: rvalue struct

[FeepingCreature]

On Monday, 30 January 2023 at 15:21:02 UTC, FeepingCreature wrote:
>
> The key insight is that we treat D like a functional language 
> at the domain level, like an object-oriented language at the 
> application level, and autogenerate everything at the 
> infrastructure level. Almost all our structs live at the domain 
> level, meaning they don't actually own state, they just 
> represent domain knowledge. State-ownership happens at the 
> application level, ie. in classes.
>

I need to emphasize this point. For instance, say that a struct 
represents "the arrival of a train at a station at a certain 
time." When we find that the train has a delay, we could mutate 
the `arrival.time` field on that struct. But what would that 
mean? The information given was *accurate* at the time. The 
struct, representing our knowledge at a certain point in time, is 
still valid. We have now gained new information, and wish to now 
replace it with an alternative value that has a different arrival 
time. But we don't want to *change the original,* ever, by any 
means! The original value is and remains a legitimate 
representation of the domain. That's why we don't use ref, or 
pointers, or state mutation in structs. Instead, we "patch" the 
variable with something like Haskell arrows [1]:

```
alias updateTimes = visit => visit
     .rebuild!(a => a.arrival = newArrivalTime)
     .rebuild!(a => a.departure = newDepartureTime);

return visits.map!(visit => visit.id == visitId ? 
updateTimes(visit) : visit);
```

or some such.

The goal of marking structs `immutable` (or `rvalue`) is to make 
any idiom that does not operate like this fail to compile.

[1] https://en.wikibooks.org/wiki/Haskell/Understanding_arrows