Things that may be removed

dsimcha dsimcha at yahoo.com
Mon Dec 22 09:31:14 PST 2008


== Quote from Don (nospam at nospam.com)'s article
> bearophile wrote:
> > There are some things I'd like to see added to the D language, but what things
can be removed from it?
> >
> > "Perfection is attained, not when no more can be added, but when no more can
be removed."
> > -- Antoine de Saint-Exupéry.
> > :-)
> >
> > "There should be one-- and preferably only one --*obvious* way to do it."
> > -- Python Zen, emphasis added by me :-)
> >
> > Bye,
> > bearophile
> That is an excellent question.
> Some items in my list are controversial, the first two have already been
> mentioned.
> * C-style declarations
> * SFINAE
> * \n, \r as a string (free up the backslash character)
> * #line (make it a pragma instead)
> * Octal (it's not 1952 any more)
> * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
> * package. In DMD, it's a broken implementation of a broken concept.
> * The postincrement and postdecrement operators (make x++, x-- identical
> to ++x, --x, except that it is illegal to use the return value.

Why?  This is a nice piece of syntactic sugar to make relatively simple code more
concise.

> Allowing
> operator overloading of the postfix operators was a silly hack in C++.
> It's a freedom nobody wants).
> * is() expressions (I love what you can do with it, but it's
> unintuitive, and traits is a much better solution)

Agreed.  I love D's compile-time reflection but there are about 100 overlapping
ways to do it, and that's a bit excessive.

> * .sort for AAs.
> * Object.toString(). Encourages bad design. It's not powerful enough to
> be useful.

Please, no.  I love Object.toString().  Sometimes, both in finished products and
when printf-debugging, it's nice to just be able to get a basic string
representation of an object.  Can you please explain how it encourages bad design?



More information about the Digitalmars-d mailing list