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

[Wanderer via Digitalmars-d]

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, whenever the result 
type is immutable or not, is the implementation detail, not part 
of the signature and should not prevent the method from being 
overridden. Removing basic operations from the root of the class 
hierarchy can cripple the whole OO model of D.

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