Re: Combining mutable objects with const references

Matti Nyk=E4nen:
> But his destructive update silently claims more than he knows: It
> claims that *nobody* will *ever* refer to the previous values, not
> even when the program is modified later.
>
> Uniqueness types/monads/... both enable and force the programmer to
> state such claims explicitly. IMO this is an example of how a software
> engineer reads (or should read) the Curry-Howard isomorphism.

But an imperative programmer is never forced to destructively update.
He can make a new object with the normal constructor, or make a copy
of another object using a copy constructor (i.e. a funcion which makes
a new object identical to an existing one).

However, I only brought the imperative example up as evidence for how
common these types of objects are (object for which it is natural to
destructively update them). I assume you aren't against the feature in
functional languages of having a syntax similar to
(p except .x =3D 5)
which destructively updates. (And it and can never mean "create a new
object" - rather, it is a compiler error if p is required elsewhere,
so it makes an explicit claim.)

So if you disagree with anything, it is that these objects are not
common, everyday objects. Is that so?

Pat