suggested improvements to D

[Warren D Smith]

Unfortunately the response to my "suggested improvements to D,"
oddly, was not uniformly "of course we'll do that immediately."

Let me reiterate my case.  First, D'ers have already agreed by consensus to add
IEEE-float hooks to handle NaNs, rounding, etc.
Good.  That means you already have admitted you
agree with my philosophy that the language
must provide the underlying power of the machine (for any feature
that a large number of machine hardwares now supply) to the user.
Not deny it.
And that means you agree this has to be done even if the syntax
for it might be a little messy. [Which doesn't matter because these
things are used fairly rarely.]

Good.  I'm glad we are in agreement.  I only ask that you now
provide hooks to allow the user to access add-with-carry, cyclic-shift
with or without carry, integer-single-to-doubleword-multiply, doublelength divide,
etc.  Because those things have been available for far longer than IEEE floating
point on far more hardware and are doable with (if anything) less-messy hooks, you
cannot logically provide the IEEE FP hooks but not these; that would be going back
on 50 years of computing wisdom and on your own admitted beliefs.

OK?  There is no question.  D'ers already agreed on this philosophy.

Next, some wondered about popcount and first1 hooks.
But then it was pointed out that, again, my opponents on this
had already lost their case - Intel soon is going to provide
these, again, in hardware, because they agree with me that they
are key instructions.  Good.  Now, referrring again to the principle
(above) that the language must provide (not deny) the underlying
power of the machine to users, again we see you have no
choice but to provide these hooks (unless you choose to go back on
your own admitted philosophy).

After you do these things, you will then be able to add to your D vs X language
comparison charts, the fact D is the only one that does not deny user access to
common hardware primitives.  (And no, sorry:
saying "you can do it by writing your own assembler" does not count as
"we provide access in the higher level language.")

This new feature of your comparison chart will
attract a multitude of users who are impressed with the fact that
finally, the designers of a language are not intentionally trying
to hurt people.

Won't that be nice?

There are even those who would go further and advocate that higher
level languages should even provide the user with access to
features NOT currently hardware-supported, but which should be,
or likely will be in future.   Thus allowing software to
drive the hardware.  Stupendous idea, is it not?
For example, microsoft BASIC provided the user the ability to multiply and divide
numbers, even though that was not available on the 8080 in hardware.  Golly gee.
Wasn't that amazing.
If D wishes to use that idea, then it might even provide
some hooks for some hardware instructions that do not currently exist,
but which have been argued in important papers (which sadly have not
yet penetrated the thick skulls of hardware designers)
to be a good thing which SHOULD exist.
The "dovetail" and "undovetail" instructions would be examples
(known to be useful in some important algorithms...),
and I could mention a few more if anybody shows interest,
e.g. instructions known to be useful to yield sub-NlogN sorting algorthms, etc.

But I do not wish to stretch you too far.  After all,
catching up to Microsoft circa 1980 in the area of language design
ideas, could be too much to ask.  Therefore, I merely ask that
D catch up to the computer hardware available in the 1980s, or
for that matter 1950s.

(Seriously: D seems to me to be pretty much making the right choices
and I've been waiting for a language with that combination of choices for over a
decade, so it'd be a pity to see D fall into the same pit of stupidity as all the
others about such an embarrassingly trivial task as providing a few builtin inline
functions.)

wds