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

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 2 02:24:12 PDT 2014


On Wed, 02 Jul 2014 07:07:17 +0000
Wanderer via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Tuesday, 1 July 2014 at 01:13:25 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > The long term plan is to remove toString, opEquals, toHash, and
> > opCmp from
> > Object so that the derived classes can decide whether to make
> > them const or
> > not. Unlike Java and C#, we have proper templates, so we can
> > templatize all of
> > the stuff in the runtime which uses those functions so that
> > they don't have to
> > be on Object.
>
> Remove toString from the root of the object hierarchy?? How do
> you plan to implement ~ operator for constructing strings? It
> should work with any types, even unbeknown to each other.

The ~ operator has nothing to do with toString. Strings are arrays, and ~
works with arrays already. ~ doesn't work with Object and will only work with
user-defined types which define opBinary!"~". The only thing that removing
toString from Object will affect would be the ability to call toString on
Object directly instead of on a reference of a derived class type, which
really doesn't lose much, since it's arguably a horrible idea to be passing
Object around anyway. All of the code in druntime and Phobos which deals with
toString is already templated, so it doesn't need to operate on Object
directly and doesn't need toString to be on Object, just on the derived types
that a program declares.

Having toString, opEquals, opCmp, and toHash on Object is fundamentally broken
in the face of const, @safe, nothrow, etc. because we're forced to either put
the attributes on them or not. If we put them on them, then those functions
are restricted by those attributes, which is unacceptable in many cases (e.g.
a class which lazily loads its members would not work with a const opEquals),
and if we don't put those attributes on them (as is currently the case), then
you can't do things like have call toString on a const object.

Given the power of D's templates, we do not need to put opEquals, toString,
opCmp, or toHash on Object. Languages like Java and C# are forced to, because
they do not have proper templates and thus have to use Object directly in many
cases. We do not have that problem, and putting those functions on Object is a
mistake from early in D's design that we need to correct in order to be able
to use @safe, const, nothrow, etc. with classes correctly.

- Jonathan M Davis


More information about the Digitalmars-d mailing list