I noticed that you describe the following for Shift Expressions in the Spec:

  It's illegal to shift by more bits than the size of the quantity being
  shifted:

     int c;
     c << 33;        error


This is one way to avoid ambiguity when shifting by large values -- such a shift isn't specified by the C standard and problems can occur if this happens.

I find that problems with shifting usually occur when the shift value is a variable which happens to exceed the width of the integer type (rather than a constant as here).  If this happens, will an error be produced or will it be ignored as in C?  (If you don't produce an error, then this doesn't prevent the problem.)

I suggest that it would be more useful if you made it legal to shift by more bits than the size of the quantity being shifted, but that in this case the result will be defined as zero; I think this is the most intuitive behaviour. It solves the problem by giving well-defined behaviour, and I think that it is less likely to cause problems when the shift accidentally gets too big or small.

(Shifting by a constant out of the range should probably produce a
compiler warning or error.)


Note that in C, a negative shift isn't defined either.  I would expect "a << -4" and "a >> 4" to be equivalent, but they are not necessarily (e.g., on Intel).  What is D's behaviour here?  I would suggest that you make these two examples equivalent.  (The alternative would be to produce an error.)


I know that this will add runtime overhead, but producing an error would add at least as much (and in any case it might be possible to optimise away some of the cases).


If you use >> on an unsigned integer, is it a signed or unsigned operation?

"Ben Cohen" <bc@skygate.co.uk> wrote in message news:9t0d0s$fu5$1@digitaldaemon.com...

> Note that in C, a negative shift isn't defined either.  I would expect "a << -4" and "a >> 4" to be equivalent, but they are not necessarily (e.g., on Intel).  What is D's behaviour here?  I would suggest that you make these two examples equivalent.  (The alternative would be to produce an error.)
>
> I know that this will add runtime overhead, but producing an error would add at least as much (and in any case it might be possible to optimise away some of the cases).

Wouldn't it add the support code that'd slow everything down even in release version (since behaviour of << on negative values should stay the same)? Bit shift is a fast and effective operation as is, one opcode, why complicate it at cost of speed?

Wouldn't it be better to throw an exception in debug version,
and ignore everything (thus producing undefined result) in release
one - like it is proposed in the specs?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9t144c$1gc7$1@digitaldaemon.com...
> Wouldn't it add the support code that'd slow everything down even in release version (since behaviour of << on negative values should stay the same)? Bit shift is a fast and effective operation as is, one opcode, why complicate it at cost of speed?
>
> Wouldn't it be better to throw an exception in debug version,
> and ignore everything (thus producing undefined result) in release
> one - like it is proposed in the specs?

That is the intent.

The trouble is that the shift instructions on the CPUs give undefined results for out of range arguments. To specify behavior means adding check code, which is unacceptable in most released apps.