<div>On Tue, Jun 11, 2013 at 11:26 AM, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span> wrote:</div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jun 11, 2013 at 01:25:24PM -0400, Steven Schveighoffer wrote:<br>
> On Tue, 11 Jun 2013 12:18:52 -0400, Adam D. Ruppe<br>
> <<a href="mailto:destructionator@gmail.com">destructionator@gmail.com</a>> wrote:<br>
><br>
> >On Tuesday, 11 June 2013 at 16:05:30 UTC, Steven Schveighoffer wrote:<br>
> >>CPU performs math at int level.<br>
> ><br>
> >eh, I wouldn't blame the hardware. You can do<br>
> ><br>
> >asm {<br>
> >   mov AL, 10;<br>
> >   add AL, 5;<br>
> >}<br>
> ><br>
> >and it is allowed, it also don't spill into AH if you overflow it<br>
> >(it just sets the carry flag). I'm sure it is different on<br>
> >different processors, but x86 is pretty flexible.<br>
><br>
> Well, that is not what I knew, so good lesson :)<br>
><br>
> But I'd be surprised if the above was less costly than a full word<br>
> addition.  I think that is the point of C's policy of integer<br>
> promotion, which D adopts for the most part (although C allows it to<br>
> go back into whatever).<br>
<br>
</div>It may or may not be less costly as full-word addition, but it<br>
definitely allows the optimizer more wiggle room, because it allows more<br>
byte-sized values to fit into registers before spilling over to memory<br>
accesses.<br>
<br>
But that doesn't really pertain to this discussion. :-P<br>
<div class="im"><br>
<br>
> >>ubyte c = k;<br>
> >>c += 1; // ok<br>
> >><br>
> >>This I find extremely inconsistent...<br>
> ><br>
> >I'd be extremely annoyed if that required a cast. It's bleeding<br>
> >obvious that you want it to assign back there....<br>
><br>
> I argue the consistency is both ways :)  I don't want to require a<br>
> cast there (and in reality, where would the cast go?), but it seems<br>
> that if you are doing math among bytes, or a byte and an integer<br>
> that can fit into a byte, it should be quite obvious that you are<br>
> working in the byte land.  The fact that<br>
><br>
> k += 1;<br>
><br>
> and<br>
><br>
> k = k + 1;<br>
><br>
> are treated differently is annoying.<br>
<br>
</div>Yeah, I agree that is annoyingly inconsistent. I'm sure there are good<br>
reasons for it -- avoid common overflow bugs, for example, while not<br>
making regular int arithmetic a pain to work with by requiring casts<br>
everywhere. But still, it *is* an inconsistency, and it's still<br>
annoying.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
T<br>
<br>
--<br>
Ruby is essentially Perl minus Wall.<br>
</font></span></blockquote></div><br></div></div><div><div>wouldn't it be a better and more consistent idea to implement bearophile's 'Compiler support to implement efficient safe integrals'</div><a href="http://d.puremagic.com/issues/show_bug.cgi?id=9850">http://d.puremagic.com/issues/show_bug.cgi?id=9850</a> so uint/int etc would require no cast</div>