<div class="gmail_quote">On Tue, Aug 9, 2011 at 1:10 PM, so <span dir="ltr"><so@so.xn--s-fka></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>

<div></div><div class="h5">On Tue, 09 Aug 2011 21:37:18 +0300, Jonathan M Davis <<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


On 8/9/2011 2:46 AM, Don wrote:<br>
> From a discussion on D.learn.<br>
><br>
> If x and y are different integral types, then in an expression like<br>
> x >> y<br>
> the integral promotion rules are applied to x and y.<br>
> This behaviour is obviously inherited from C, but why did C use such a<br>
> counter-intuitive and bug-prone rule?<br>
> Why isn't typeof(x >> y) simply typeof(x) ?<br>
> What would break if it did?<br>
><br>
> You might think the the rule is that typeof( x >> y) is typeof( x + y),<br>
> but it isn't: the arithmetic conversions are NOT applied:<br>
> typeof(int >> long) is int, not long, BUT<br>
> typeof(short >> int) is int.<br>
> And we have this death trap (bug 2809):<br>
><br>
> void main()<br>
> {<br>
> short s = -1;<br>
> ushort u = s;<br>
> assert( u == s );<br>
> assert ( (s >>> 1) == (u >>> 1) ); // FAILS<br>
> }<br>
<br>
That last is why we can't just change the behavior from C.<br>
</blockquote>
<br></div></div><div class="im">
The question though is whether that is ever _desired_ behavior in a C program.<br>
If it's always a bug when it happens, then I'd argue that we can and should<br>
change the behavior. If there's a legitimate reason why could would want the C<br>
behavior, then changing it in D would cause problems for porting code, but if<br>
the difference only matters when there's a bug in the C code, then breaking<br>
compatibility is only an issue for broken code, and changing it would help<br>
prevent issues in D.<br>
<br>
- Jonathan M Davis<br>
</div></blockquote>
<br>
Can't we finally get rid of this compatibility issue by separating?<br>
. for the whole file which can be enabled with a flag to compiler "dmd -Cmode ...."<br></blockquote><div><br></div><div>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. </div>

</div>