RfC for language feature: rvalue struct

Dukc ajieskola at gmail.com
Mon Jan 30 20:15:48 UTC 2023


On Monday, 30 January 2023 at 15:31:59 UTC, FeepingCreature wrote:
>
> 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.

I see. The idea about immutability is good IMO, but your ways to 
achieve that are different from mine. My way would be to have the 
original struct be `immutable`, which protects the fields, but 
have the value under construction be mutable with public fields. 
Data pointed to by any arrays or pointers in the `struct` would 
still be `immutable`.

I don't see a need for fields to be non-referenceable since 
immutability protects them if the data in question is already 
committed.


More information about the Digitalmars-d mailing list