Bug or Feature? compile error: to!string(const Object)

[Timon Gehr via Digitalmars-d]

On 07/03/2014 05:16 AM, Wanderer wrote:
> On Wednesday, 2 July 2014 at 17:21:36 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
>> By not putting these functions on Object, it allows them to have whatever
>> attributes they need when declared in derived types. Without that,
>> we're stuck
>
> That's not the problem of the Object class, that's the problem of D
> syntax that doesn't allow to override a "normal" method with "const"
> method of the same signature. Whenever the body of the method touches
> argument's internals or not,

Yes, int opCmp(Object) -> int opCmp(const Object)const wouldn't be 
unsound (but there are workarounds.)

But what one actually wants is closer to int opCmp(const typeof(this))const.

> whenever the result type is immutable or not,

Example?

> is the implementation detail, not part of the signature and should
> not prevent the method from being overridden.

> Removing basic operations

Because, indeed, what is more basic than throwing an exception on 
attempted comparison of arbitrary unrelated class instances. The other 
methods being defined on arbitrary objects does not actually buy a whole 
lot either.

> from the root of the class hierarchy can cripple the whole OO model of D.
> ...

If 'cripple the whole OO model' means 'remove the methods of the root 
class', then yes. (Seriously, what is it actually supposed to mean?)

>> with whatever attributes are on the one in Object, which is unacceptably
>> restrictive. The _only_ thing we lose here is the ability to call any
>> of these
>> functions on Object directly, which arguably is no real loss.
>>
>> - Jonathan M Davis
>
> Look at this from this point: a programmer new to D, writes his first
> class. Then he tries to sort a collection/array of such newborn objects,
> and - apparently - gets a compiler error because "your class doesn't
> define opCmp".

Wonderful. The current behaviour is a runtime crash. (And there was a 
time when your objects would silently end up sorted by the signed low 32 
bits of their in-memory address (Usually. Implementing opCmp as 
exp(lhs)-exp(rhs) is not actually valid due to the possibility of 
overflow 
https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d#L100).)

> He wants to fix that by adding the method. Question:
> where should he read about what opCmp is, what arguments it takes, what
> value returns, and the most important, what basic rules it should comply
> with? If these things aren't defined in Object anymore, where they
> should be defined instead? If there is no easy access to opCmp's
> contract, what the chances are that the method will be written correctly?

http://lmgtfy.com/?q=dlang+opCmp&l=1