On Wednesday, 11 July 2012 at 18:21:24 UTC, Steven Schveighoffer
wrote:
On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix
<deadal...@gmail.com> wrote:
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's
take something
obvious like a class object representing a dataset in a
database. How is
an immutable instance of such a class useful?
This is a good point. It seems we're subjecting all classes
to certain
limitations for the benefit of a subset of those classes.
Andrei
Did you saw the proposal of feep/tgehr on #d ?
It basically state that you can overload a const method with a
non const one if :
- You don't mutate any data that belong to the parent.
- You are prevented to create any immutable instance of that
classe or any subclasse.
I don't like this idea. It means you could not use pure
functions to implicitly convert mutable class instances to
immutable (something that should be possible today).
I do like the idea. Please explain by example why a pure function
could no longer convert mutable class instances to immutable? The
proposal to restrict the use of immutable is only supposed to
affect classes that specifically request it.
It also seems to allow abuses. For example:
class A
{
private int _x;
public @property x() const { return _x; }
}
class B : A
{
private int _x2;
public @property x() { return _x2++; }
}
I think you would have to mark B somehow to indicate that
immutable(B) is now illegal, e.g.
@mutating class B : A
{
private int _x2;
public @property override x() { return _x2++; }
}
Now I've completely changed the logistics of the x property so
that it's essentially become mutable.
This kind of perversion is already possible when x() is const.
x() is allowed to mutate and return a static or global variable.
