Congratulations to the D Team!

[Steven Schveighoffer]

On Wed, 11 Jul 2012 14:29:28 -0400, deadalnix <deadalnix at gmail.com> wrote:

> 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.

The expectation is that x belongs to the class, not elsewhere.  In fact,  
the derived type does not change that expectation, it *does* belong to the  
class.

In effect, with this proposal we have logic const, with a shitty  
implementation requirement (I have to derive to another class in order to  
achieve it).

If we want to implement logical const, let's do it clearly and minimal.

-Steve