Congratulations to the D Team!

[deadalnix]

On 11/07/2012 20:21, Steven Schveighoffer wrote:
> On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix <deadalnix at 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).
>
> 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++; }
> }
>
> Now I've completely changed the logistics of the x property so that it's
> essentially become mutable. In effect, I overrode the const piece of x
> completely to make it non-const without a cast, and anyone calling x()
> on an A instance cannot trust that it won't increment the effective
> value of x().
>
> I think the solution to this overall problem is simply to make
> object.opEquals use the most derived types available for comparison.
>
> -Steve

I see no problem here. x isn't pure, so it isn't required to give back 
the same result each time it is used.