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