Why do shift operators undergo integral promotion?

[Jonathan M Davis]

> On Wed, 10 Aug 2011 00:57:17 +0300, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> >> 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.
> 
> What you are saying just covers the language being a C like language,
> aren't we talking about the restriction and threat it pose to the language?
> 
> > D breaks compatibility all over the place. It just doesn't do it when C
> > code would be valid D code.
> 
> I am afraid this is not quite right. Wouldn't it be oxymoron when you
> reject every solution/idea using this argument? It doesn't matter if the
> idea has no merit or it was the meaning of life.

??? One of the rules of language design that Walter has stuck to throughout 
the development of D is that if you take any C or C++ code and try to compile 
it as D code, it will either fail to compile, or it will compile with the same 
behavior as the code would have had in C or C++. This is so that you don't 
silently introduce bugs when porting code from C or C++ to D.

There's _lots_ of stuff in D that isn't valid C code, and there's plenty of 
stuff in C which isn't valid D code. Saying that C/C++ code must either be 
valid D code with the same behavior or not compile is not particularly 
restrictive on the whole. It's really only an issue with some arithmetic 
stuff. D is free to add additional restrictions (such as requiring casts for 
narrowing conversions), and it can do whatever it wants which is different 
from C as long as it isn't valid C - and almost everything that D does is 
different enough that it's almost a non-issue.

You'd actually probably have a hard time trying to come up with a feature to 
introduce to the language which would be valid C but have different behavior 
in D than C. The common stuff is the really basic stuff like arithmetic and 
pointers, which isn't really where you're going to be adding features. The 
only issue with it really is that there are a few rough edges in C with 
regards to arithmetic. Anyone looking for a drastically different way of 
handling math between different integer types, for instance, is going to be 
out of luck. But there's not much beyond that which is strictly compatible 
with C. D is just too different from C for that small amount of compatibility 
to be much of an issue. It does crop up periodically but not often, and it's a 
whole world of difference from how C++ treats compatibility with C.

- Jonathan M Davis