The current signatures for opCmp/opEqual mean that code like:


bool strictly_ordered(T)(in T[] list) {
    for (auto j = 1; j < list.length; j++) {
        if (list[j - 1] >= list[j])
            return false;
    }
    return true;
}

will fail to compile if T is a class because opCmp cannot be called with a const argument.  This restricts the quality of code that can be written by limiting legitimate use of in/const arguments to functions/methods.

Trying to work around this problem by defining opCmp/opEquals for the class being used with in or const argument does not work as they are not recognised as an override of the Object methods.

So my question is "Why are the arguments to opEquals and opCmp (for Objects) not declared in or const?".

Thanks
Peter

On 03/18/2013 12:19 AM, Peter Williams wrote:
> The current signatures for opCmp/opEqual mean that code like:
>
>
> bool strictly_ordered(T)(in T[] list) {
>      for (auto j = 1; j < list.length; j++) {
>          if (list[j - 1] >= list[j])
>              return false;
>      }
>      return true;
> }
>
> will fail to compile if T is a class because opCmp cannot be called with
> a const argument.  This restricts the quality of code that can be
> written by limiting legitimate use of in/const arguments to
> functions/methods.
>
> Trying to work around this problem by defining opCmp/opEquals for the
> class being used with in or const argument does not work as they are not
> recognised as an override of the Object methods.
>

Yes they are.

> So my question is "Why are the arguments to opEquals and opCmp (for
> Objects) not declared in or const?".
>

Because not all valid implementations can be. They shouldn't be in Object anyway.

On 03/18/2013 01:16 AM, Timon Gehr wrote:
> On 03/18/2013 12:19 AM, Peter Williams wrote:
>> The current signatures for opCmp/opEqual mean that code like:
>>
>>
>> bool strictly_ordered(T)(in T[] list) {
>>      for (auto j = 1; j < list.length; j++) {
>>          if (list[j - 1] >= list[j])
>>              return false;
>>      }
>>      return true;
>> }
>>
>> will fail to compile if T is a class because opCmp cannot be called with
>> a const argument.  This restricts the quality of code that can be
>> written by limiting legitimate use of in/const arguments to
>> functions/methods.
>>
>> Trying to work around this problem by defining opCmp/opEquals for the
>> class being used with in or const argument does not work as they are not
>> recognised as an override of the Object methods.
>>
>
> Yes they are.

Actually you are right.

>
>> So my question is "Why are the arguments to opEquals and opCmp (for
>> Objects) not declared in or const?".
>>
>
> Because not all valid implementations can be. They shouldn't be in
> Object anyway.

On Monday, March 18, 2013 01:20:40 Timon Gehr wrote:
> >> So my question is "Why are the arguments to opEquals and opCmp (for Objects) not declared in or const?".
> > 
> > Because not all valid implementations can be. They shouldn't be in Object anyway.

Yeah. It was agreed that opCmp, opEquals, toString, and toHash would be removed from Object, since they don't need to be there and cause unnecessary issues with const, but AFAIK, no work has been done yet to make that that work. I would of the things that would likely have to be finished first would be the refactoring of the built-in AAs so that they're templated types internally, and I'm sure that there are similar roadblocks that will need to be sorted out. Long term though, none of that needs to be on Object and should be left to derived classes to add with whatever constness (or @safety or whatever) that is appropriate for them.

- Jonathan M Davis

On 17/03/2013 23:19, Peter Williams wrote:
<snip>
> So my question is "Why are the arguments to opEquals and opCmp (for Objects) not declared
> in or const?".

Known bug.

http://d.puremagic.com/issues/show_bug.cgi?id=1824

This was reported 5 years ago, and it's a serious issue, so I don't know why it's taking so long to get it sorted.

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

On Monday, 18 March 2013 at 00:46:46 UTC, Stewart Gordon wrote:
> On 17/03/2013 23:19, Peter Williams wrote:
> <snip>
>> So my question is "Why are the arguments to opEquals and opCmp (for Objects) not declared
>> in or const?".
>
> Known bug.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=1824
>

I did look in bugs but failed to find this.

Thanks for the reference.
Peter

On 18/03/2013 00:34, Jonathan M Davis wrote:
> On Monday, March 18, 2013 01:20:40 Timon Gehr wrote:
>>>> So my question is "Why are the arguments to opEquals and opCmp (for
>>>> Objects) not declared in or const?".
>>>
>>> Because not all valid implementations can be. They shouldn't be in
>>> Object anyway.
>
> Yeah. It was agreed that opCmp, opEquals, toString, and toHash would be
> removed from Object, since they don't need to be there and cause unnecessary
> issues with const,

What are these "unnecessary issues with const" they cause?

I agree with doing away with Object.opCmp as it doesn't make sense to pretend that artibrary objects can be ordered in relation to each other.  Not sure about the others. But how would we go about this without causing far more disruption than making these methods const would?

> but AFAIK, no work has been done yet to make that that
> work. I would of the things that would likely have to be finished first would be
> the refactoring of the built-in AAs so that they're templated types
> internally, and I'm sure that there are similar roadblocks that will need to
> be sorted out. Long term though, none of that needs to be on Object and should
> be left to derived classes to add with whatever constness (or @safety or
> whatever) that is appropriate for them.

Why would some class want to implement these methods in a way that alters the object?

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

On Monday, 18 March 2013 at 00:16:17 UTC, Timon Gehr wrote:
> On 03/18/2013 12:19 AM, Peter Williams wrote:
>> The current signatures for opCmp/opEqual mean that code like:
>>
>>
>> bool strictly_ordered(T)(in T[] list) {
>>     for (auto j = 1; j < list.length; j++) {
>>         if (list[j - 1] >= list[j])
>>             return false;
>>     }
>>     return true;
>> }
>>
>> will fail to compile if T is a class because opCmp cannot be called with
>> a const argument.  This restricts the quality of code that can be
>> written by limiting legitimate use of in/const arguments to
>> functions/methods.
>>
>> Trying to work around this problem by defining opCmp/opEquals for the
>> class being used with in or const argument does not work as they are not
>> recognised as an override of the Object methods.
>>
>
> Yes they are.
>
>> So my question is "Why are the arguments to opEquals and opCmp (for
>> Objects) not declared in or const?".
>>
>
> Because not all valid implementations can be.

Can't those (rare) implementations just do a non constant cast when they cast Object to their desired class?

> They shouldn't be in Object anyway.

Yes, if they could just be declared without overriding the problem would go away but whichever solution is chosen existing code would need minor changes.

Peter

On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
> Why would some class want to implement these methods in a way that alters the object?

Because const in D is physical const, not logical const. So, for instance, const prevents caching. And it's quite possible that a type which really cared about efficiency would cache the calculated value for toHash. Make toHash const would make that impossible. Another possible problem would be lazy initialization. If opEquals is const, then lazy initialization becomes impossible.

We've discussed this on a number of occasions, and it's clear that forcing these functions to be const is a major problem, and yet they do need to be const for them to work with const objects. What was finally decided during the last big discussion on this a few months back was that we would remove opEqulas, opCmp, toHash, and toString from Object. They don't need to be there. As long as everything in the runtime which deals with them is templated, then there's no technical reason why Object would need them. D isn't Java where we have containers of Object or anything like that. Putting them on Object just restricts us.

So, once all of those functions are removed from Object, derived types can then define them with whatever attributes they want. The only thing you lose is the ability to compare Objects directly, which is not necessary in D and is arguably a bad idea anyway.

The work on this conversion hasn't been done yet, and a transition plan will have to be put in place to minimize code breakage, but that's what was decided on as the solution to the issues with const and Object's functions.

- Jonathan M Davis

On Monday, March 18, 2013 02:00:37 Peter Williams wrote:
> Can't those (rare) implementations just do a non constant cast when they cast Object to their desired class?

No. In D, casting away const on an object and mutating it is undefined behavior.

- Jonathan M Davis