Why do shift operators undergo integral promotion?

[Jonathan M Davis]

> On Wed, 10 Aug 2011 00:08:02 +0300, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > There's no reason to have a separate version of the language which is
> > more
> > compatible with C than another version. It would just complicate things.
> > 
> > Not
> > only would it be a burden on the compiler maintainers, but then you
> > would have
> > to know whether code was intended to be compiled with the standard D
> > compiler
> > or with the one which is more compatible with C. It would be a mess for
> > very
> > little benefit.
> 
> I see having a compiler flag is a bad idea, it would be entirely in the
> source code.
> It is not about having more/less compatible compilers. There is only one
> compiler to be maintained and it is D.
> Getting rid of such a restriction (C compatibility) would be priceless i
> can't express, and i don't understand why it is not obvious.
> Our problem is this very restriction. D should be called "C like (easy to
> learn if you know C/C++) and supports C natively", not "C compatible".
> Because if being out of date was the only thing wrong about C then someone
> would just add some modern features and call it maybe... C++-+%?

In general, it's not a problem at all. It's only relevant when the C/C++ code 
is valid D code. It often isn't. For the most part, the code which is both 
valid C/C++ code and valid D code is valid Java code and valid C# code as well 
(the primary exception that I can think of being pointers). It's stuff which 
is common across C-based languages and would screw over programmers pretty 
thoroughly if it changed. There are a few exceptions (such as this issue with 
the shift operator) which are a problem, but for the most part, it's really 
not an issue. It's trying to maintain C++'s level of compatibility with C 
where you really get into trouble. D does _not_ maintain anything even close 
to that level of compatability. It just chooses to be compatible when the 
syntax is identical so that code which is ported from C or C++ doesn't 
silently break.

So, while from what I can see, I think that in this particular case, it would 
be a good idea to fix C's behavior rather than follow it, I think that you're 
blowing the issue of general C compatibility out of proportion. D breaks 
compatibility all over the place. It just doesn't do it when C code would be 
valid D code.

- Jonathan M Davis