Andrei Alexandrescu , dans le message (digitalmars.D:171828), a écrit :
> On 7/10/12 5:19 PM, H. S. Teoh wrote:
>
> There is value in immutable objects that has been well discussed, which
> is incompatible with logical constness. We can change the language such
> as: a given type X has the option to declare "I want logical const and
> for that I'm giving up the possibility of creating immutable(X)". That
> keeps things proper for everybody - immutable still has the strong
> properties we know and love, and such types can actually use logical const.
>
> A number of refinements are as always possible.
I think this is a good idea, but for classes, inheritance is an issue.
Example:
class A
{
int a;
int compute() const pure { return a; }
final int fun() const pure
{
a.compute; // optimised out by the compiler
return a.compute;
}
}
class B : A
{
@mutable int b;
override int compute() const pure
{
if(!b) b = longComputation(a);
// a += 1; // error, a is bitwise-const
return b; // mutating and returning a mutable part at the
// programmer's risk
}
}
A.compute is bitwise const. However B.compute is logical const. A.fun is
bitwise const, and can be optimised. But that is no longer true with a B
instance. However, the compiler must be able to make those
optimizations, otherwise all the power of const for any non final object
is lost, because someone may derive a logical const class. This means
the programmer is *responsible* for creating a logical const-behavior.
This is a serious issue.
Given the system-programming aspect of D, I would say the programmer
should be allowed to do such a thing, taking the risk to have an
undefined behavior. But with great caution. At least, it will be less
dangerous than casting away const. Just providing a way to make it
impossible to create an immutable instance of some classes would make it
less dangerous to cast away constness.
--
Christophe
