It is nice that Michel Fortin made the effort to propose a patch
trying to address the ability to rebind const objects.
Looking at the "uglification" of my code to support const, I saw that
many cases I actually had a unique type, or partially unique type.
There are several examples of similar attempts, like linear types, or
various uniqueness types systems (more or less related to the Clean
example).
It is known that some uniqueness settings are equivalent to shared, so
maybe using uniqueness with const might be meaningful.
This is a difficult topic, as pushing those concepts into the type
system is always tricky, and the consequences of various choices are
often non obvious, anyway here is what I thought.
If one could declare return or out types as unique (note that unique
is *not* part of the type, it is like the storage attributes), these
methods could be implicitly castable to const or immutable, allowing
nicer code.
Constructors *might* return unique objects (an object is unique only
if all its references are to unique or immutable objects).
In several cases uniqueness could be checked by the compiler. I think
that such a change would improve part of my code, removing the need
for several spurious casts, while at the same time making the code
safer.
I did also think about having a front_unique attribute that can be
applied to any local variable or argument that would make it tail
const in the sense discussed previously, and still implicitly castable
to full const.
In that case the situation is more complex (one should ensure that
local references cannot spill out, otherwise a full const is needed,
and for immutable, making it immutable is "irreversible".
The front_unique property can almost always be checked by the
compiler, but activating it implicitly would have effects that would
probably deemed surprising by the programmer (front_unique immutable
objects would be rebindable).
Thus I am not sold on front_unique, but I still find it interesting,
due to its relationship with tail const.
Fawzi
