Why do shift operators undergo integral promotion?

[Jonathan M Davis]

> On Tue, 09 Aug 2011 23:20:02 +0300, Andrew Wiley
> 
> <wiley.andrew.j at gmail.com> wrote:
> >> Can't we finally get rid of this compatibility issue by separating?
> >> . for the whole file which can be enabled with a flag to compiler "dmd
> >> -Cmode ...."
> > 
> > That would essentially mean we have two compilers to maintain at the end
> > of
> > the day because the semantics of certain operations would depend
> > entirely on
> > whether the compiler was in C mode or not.
> 
> True, but we are now doing something similar (probably something much
> harder) which unlikely produces a positive outcome.
> We say there is a compatibility where there was not (to which extend no
> one knows), on the other hand there are new rules/syntax for the same
> problems in the same language which would create awful amount of
> confusion, not to mention ignoring the solutions to the problems.
> 
> On maintaining two compilers, i don't think this is a bigger issue because
> C compiler and spec already here and never changes.

Generally speaking, when C or C++ code compiles as D code, it has identical 
behavior (there are a few exceptions - such as passing static arrays - but 
it's almost always true). The reason for this is so that you don't end up with 
tons of bugs when porting code to D from C or C++. If it weren't for that, 
then corner cases such as this wouldn't really matter, and we could just make 
D to the smart thing. But because we don't want code which is ported to break 
in all kinds of subtle ways, we maintain compatibility with C/C++ as long as 
the C/C++ code is valid D code.

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.

The question here is whether we can safely make the change to D's behavior 
without breaking code which is ported from C or C++. As long as it is pretty 
much a guarantee that any code which relies on the C behavior is buggy, then I 
don't see any reason why we can't fix the behavior in D. However, if there are 
valid reasons for C code to rely on the C behavior, then we're kind of stuck. 
>From what I can see though, it sure looks like any C code which relies on the 
C behavior would be buggy.

- Jonathan M Davis