On 07/11/2012 08:17 PM, Andrei Alexandrescu wrote:
> On 7/11/12 2:03 PM, Timon Gehr wrote:
>> I think they should be pure as much as I think they should be const.
>>
>> The reasoning is analogous for both.
>>
>> We have immutable class instances that want to provide the methods =>
>> make them const.
>>
>> We have pure functions that want to provide the methods => make them
>> pure.
>>

oops. I meant to write "We have pure functions that want to use the methods."

>> This reasoning is not taking into account the whole picture because
>>
>> We have implementations of those methods that want to use non-const
>> methods in their implementation. (eg. database connection)
>>
>> We have implementation of those methods that want to use non-pure
>> methods in their implementation (eg. database connection, logging)
>
> The essential difference is there's no "pure" object, so there's no
> motivation to plant "pure" on its methods.
>
> Andrei


auto foo(Object o)pure{
    // o is a "pure" object here
}

On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix <deadalnix@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

On 11/07/2012 20:21, Steven Schveighoffer wrote:
> On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix <deadalnix@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.

On Wednesday, 11 July 2012 at 18:21:24 UTC, Steven Schveighoffer wrote:
...
> 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 thought about this example. You can have a const method returning different values anyway (instead of returning what base class' method would return), and A._x has not been mutated. From my point of view, it is just a different concept, but arguably not a worse one.

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

> On 11/07/2012 20:21, Steven Schveighoffer wrote:
>> On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix <deadalnix@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

On 07/11/2012 08:18 PM, Andrei Alexandrescu wrote:
> On 7/11/12 2:07 PM, H. S. Teoh wrote:
>> On Wed, Jul 11, 2012 at 01:49:53PM -0400, 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.
>> [...]
>>
>> Yes, that's what we've been trying to say for the last, oh, 100
>> messages? ;-)
>
> I didn't see that, sorry. What's the closest quote?
>
> Andrei
>
>

This is rather close, if put less eloquently:

On 07/11/2012 03:45 AM, Timon Gehr wrote:
> But why should I sprinkle my code with 'const' anyway? Almost
> none of its classes will actually be instantiated with the immutable
> qualifier.

This expresses the desire to classify objects into those that can
support the interface and those that cannot:

On 07/09/2012 01:44 PM, Timon Gehr wrote:
> // object.di
> class RawObject { }
> class Object : RawObject { ... }
>
> // user.d
> class C { }             // inherits from Object
> class D : RawObject { } // this does not

On Wed, 11 Jul 2012 14:21:24 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:


> 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++; }
> }
>

Another abuse:

const(B) b = new B;
// auto bx = b.x; // oops, compiler error
const(A) a = b;
auto bx = a.x;

-Steve

On 11/07/2012 20:53, Steven Schveighoffer wrote:
> On Wed, 11 Jul 2012 14:21:24 -0400, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>
>
>> 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++; }
>> }
>>
>
> Another abuse:
>
> const(B) b = new B;
> // auto bx = b.x; // oops, compiler error
> const(A) a = b;
> auto bx = a.x;
>
> -Steve

This shouldn't be a compiler error. An object of type B is 100% of time mutable now.

On Wed, 11 Jul 2012 15:14:19 -0400, deadalnix <deadalnix@gmail.com> wrote:

> On 11/07/2012 20:53, Steven Schveighoffer wrote:
>> On Wed, 11 Jul 2012 14:21:24 -0400, Steven Schveighoffer
>> <schveiguy@yahoo.com> wrote:
>>
>>
>>> 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++; }
>>> }
>>>
>>
>> Another abuse:
>>
>> const(B) b = new B;
>> // auto bx = b.x; // oops, compiler error
>> const(A) a = b;
>> auto bx = a.x;
>>
>> -Steve
>
> This shouldn't be a compiler error. An object of type B is 100% of time mutable now.

According to my code, b is const, and never was mutable.

If you are saying that I should be able to call b.x, then this proposal is even worse than I thought!  I have no idea what const means in this world.

-Steve

Andrei Alexandrescu , dans le message (digitalmars.D:171945), a écrit :
> 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.

Does Object really need to implement opEquals/opHash/... ? This is what limits all classes that do not want to have the same signature for opEquals.

The problem is not only in the constness of the argument, but also in its purity, safety, and throwability (although the last two can be worked arround easily).

You can compare struct, all having different opEquals/opHash/.... You can put them in AA too. You could do the same for classes. Use a templated system, and give the opportunity for the class to provide its own signature ? There may be code bloat. I mean, classes will suffer from the same code bloat as structs. Solutions can be found reduce this code bloat.

Did I miss an issue that makes it mandatory for Object to implement opEquals and friends ?

-- 
Christophe