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
