On Tue, Jun 11, 2013 at 01:25:24PM -0400, Steven Schveighoffer wrote: > On Tue, 11 Jun 2013 12:18:52 -0400, Adam D. Ruppe > <destructiona...@gmail.com> wrote: > > >On Tuesday, 11 June 2013 at 16:05:30 UTC, Steven Schveighoffer wrote: > >>CPU performs math at int level. > > > >eh, I wouldn't blame the hardware. You can do > > > >asm { > > mov AL, 10; > > add AL, 5; > >} > > > >and it is allowed, it also don't spill into AH if you overflow it > >(it just sets the carry flag). I'm sure it is different on > >different processors, but x86 is pretty flexible. > > Well, that is not what I knew, so good lesson :) > > But I'd be surprised if the above was less costly than a full word > addition. I think that is the point of C's policy of integer > promotion, which D adopts for the most part (although C allows it to > go back into whatever).
It may or may not be less costly as full-word addition, but it definitely allows the optimizer more wiggle room, because it allows more byte-sized values to fit into registers before spilling over to memory accesses. But that doesn't really pertain to this discussion. :-P > >>ubyte c = k; > >>c += 1; // ok > >> > >>This I find extremely inconsistent... > > > >I'd be extremely annoyed if that required a cast. It's bleeding > >obvious that you want it to assign back there.... > > I argue the consistency is both ways :) I don't want to require a > cast there (and in reality, where would the cast go?), but it seems > that if you are doing math among bytes, or a byte and an integer > that can fit into a byte, it should be quite obvious that you are > working in the byte land. The fact that > > k += 1; > > and > > k = k + 1; > > are treated differently is annoying. Yeah, I agree that is annoyingly inconsistent. I'm sure there are good reasons for it -- avoid common overflow bugs, for example, while not making regular int arithmetic a pain to work with by requiring casts everywhere. But still, it *is* an inconsistency, and it's still annoying. T -- Ruby is essentially Perl minus Wall.