Does D have too many features?

[Don Clugston]

On 30/04/12 12:27, Manu wrote:
> On 30 April 2012 10:32, Don Clugston <dac at nospam.com
> <mailto:dac at nospam.com>> wrote:
>
>     On 29/04/12 20:08, Manu wrote:
>
>         On 29 April 2012 18:50, Don <nospam at nospam.com
>         <mailto:nospam at nospam.com>
>         <mailto:nospam at nospam.com <mailto:nospam at nospam.com>>> wrote:
>
>
>             On 28.04.2012 20:47, Walter Bright wrote:
>
>                 Andrei and I had a fun discussion last night about this
>                 question. The
>                 idea was which features in D are redundant and/or do not add
>                 significant
>                 value?
>
>                 A couple already agreed upon ones are typedef and the
>         cfloat,
>                 cdouble
>                 and creal types.
>
>                 What's your list?
>
>
>             * The >>> operator, which does nothing except introduce bugs (It
>             does NOT perform an unsigned shift).
>
>
>         What does it do? I use this all over the place, I assumed it
>         worked...
>         maybe I have bugs?
>
>
>     It works only for two types: int and long.
>     For everything else, it is identical to >>
>     So for short and byte, and in generic code, it's ALWAYS a bug.
>
>
> O_O
> Is that intentional? Or is it... a bug?
> I smiled when I saw >>> in the language, I appreciate its presence. It's
> not necessary, but it cuts down on some ugly explicit casting (which
> theoretically makes generic code simpler).

It's not a bug, it's a design flaw. The buggy behaviour is explicitly 
tested in the test suite.
The problem is that the C promotion rules also apply, just as for >> and 
<<. But they are fundamentally incompatible with unsigned shift.
So short and byte get promoted to int *by sign extension*,
then the int gets an unsigned shift.
Which means that the short or byte gets a signed shift instead of an 
unsigned one.

I used to use >>> in my code, because as you say, it is a nice idea, but 
after having a few bugs with short, and working out what the semantics 
actually were, I suddenly realized it was a landmine, and I removed 
every instance of it from my code.

(cast(ulong)x) >> 3 is safer than x >>> 3, unfortunately.