On Wednesday, 12 June 2013 at 01:35:47 UTC, Adam D. Ruppe wrote:
> 	// byte multiplication, answer goes into a 16 bit register, but we could truncate it too


BTW just as a personal note you might be amused by, this multiply instruction beat the crap out of me when I was learning x86 assembly back in the day. Figuring out what was multiplied by what and where the answer went took me an embarrassingly long time, so I avoided mul and div for quite a while when coding. I'd say mul is slow anyway so that's why I was avoiding it, but the truth was I just didn't know how it worked! The instruction sheet saying the product is stored in DX:AX didn't help much, I remember thinking it meant a memory address and getting all kinds of nonsense trying to read from it....

So I'm talking now partially because I'm a bit proud to know all this stuff after my early failures all that time ago.

On Tue, 11 Jun 2013 20:58:17 -0400, Ali Çehreli <acehreli@yahoo.com> wrote:

> On 06/11/2013 05:48 PM, captaindet wrote:
>
>  > i think part of the problem is that '1' is an int. so the calculation
>  > must be promoted to integer.

No, the compiler knows that 1 could fit in a ubyte.  It has value-range-propagation.  Changing 1 to a ubyte type would not fix the problem.

The issue is the integer promotion when doing arithmetic.

> According to "Integer Promotions" and "Usual Arithmetic Conversions" there is no arithmetic operation that is executed in any type narrower than int:
>
>    http://dlang.org/type.html

This is exactly right, and the rule is:

"4. Else the integer promotions are done on each operand..."

which means both are upgraded to int before anything else occurs.

-Steve

On 2013-06-11 19:48, captaindet wrote:
> On 2013-06-11 07:35, Adam D. Ruppe wrote:
>> On Tuesday, 11 June 2013 at 10:12:27 UTC, Temtaime wrote:
>>> ubyte k = 10;
>>> ubyte c = k + 1;
>>>
>>> This code fails to compile because of: Error: cannot implicitly
>>> convert expression (cast(int)k + 1) of type int to ubyte
>>
>> The reason is arithmetic operations transform the operands into ints,
>> that's why the error says cast(int)k. Then it thinks int is too big
>> for ubyte. It really isn't about overflow, it is about truncation.
>>
>> That's why uint + 1 is fine. The result there is still 32 bits so
>> assigning it to a 32 bit number is no problem, even if it does
>> overflow. But k + 1 is promoted to int first, so it is a 32 bit
>> number and now the compiler complains that you are trying to shove it
>> into an 8 bit variable. Unless it can prove the result still fits in
>> 8 bits, it complains, and it doesn't look outside the immediate line
>> of code to try to prove it. So it thinks k can be 255, and 255 + 1 =
>> 256, which doesn't fit in 8 bits.
>>
>> The promotion to int is something D inherited from C and probably
>> isn't going anywhere.
>
> i think part of the problem is that '1' is an int. so the calculation must be promoted to integer.
> if we had byte and ubyte integer literals (suffix b/B and ub/UB?), then if all RHS arguments are (unsigned) bytes the compiler could infer that we are serious with sticking to bytes...
>
> ubyte k = 10; // or optional 10ub
> ubyte c = k + 1ub;

clarification: i was only half serious. i understand that indicating a byte literal is not enough and that the promotion rules would have to be altered too. however, i think it would be backwards compatible. then the question is if enough ppl want this feature badly enough to push the issue. i don't think this is the case meaning we will have to accept this little quirk.