Uranuz:

> Why there are so complicated rules in the *new* language.
> It's hard to understand the logic.

Despite D being only 14 years old, one of its rules is to (usually) give the same results if you write code that is valid in C. This means it has to follow many rules of C language. If you try your code in C you will see some similar results. This rule of D is quite handy.

Other reasons for the current design of D is that sometimes practicality beats design purity, because D is an engineering product.

And I guess another reason is that Walter is not a mathematician nor a computer science theorist, so he has not seen some more principled designs, or he has not appreciated them because of their more formal nature.

Bye,
bearophile

If these rules are not so clear and have some exceptions (but I don't understand why they are needed) then some documentation needed about this. But I would prefer to have result of uint substraction like uint, and char substraction like char. If we will changing all the types it will be kind of mess. Using this logic we should have some bigger type for int multiplication operator to fit in result of multiplication of int.max*int.max. I know that some assembler operations do this and multiplication of two registers with byte size results in placing product into two result register. But in context of higher level programming language it's better to have better type consistensy. Or we will nead a bigger type to store product for ulong.max*ulong.max result. Is it good or not?

On Sun, 22 Jun 2014 08:23:45 -0400, Uranuz <neuranuz@gmail.com> wrote:

> If these rules are not so clear and have some exceptions (but I don't understand why they are needed) then some documentation needed about this.

See integer promotion rules:

http://dlang.org/type.html#Integer%20Promotions

And the section below it.

-Steve

On Monday, 23 June 2014 at 18:32:38 UTC, Steven Schveighoffer wrote:
> On Sun, 22 Jun 2014 08:23:45 -0400, Uranuz <neuranuz@gmail.com> wrote:
>
>> If these rules are not so clear and have some exceptions (but I don't understand why they are needed) then some documentation needed about this.
>
> See integer promotion rules:
>
> http://dlang.org/type.html#Integer%20Promotions
>
> And the section below it.
>
> -Steve

I see these rules but when I compile following code and it fails with error it looks VERY stupid.

import std.stdio;

void main()
{
	ubyte a = 15;
	ubyte b = 10;
	
	ubyte c = a + b; //What is happening there?! AAAAARGH! Are you joking?!
	
}

Compilation output:
/d837/f382.d(9): Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of type int to ubyte

I'm just crazy about it! How could it happen?!

> I see these rules but when I compile following code and it fails with error it looks VERY stupid.
>
> import std.stdio;
>
> void main()
> {
> 	ubyte a = 15;
> 	ubyte b = 10;
> 	
> 	ubyte c = a + b; //What is happening there?! AAAAARGH! Are you joking?!
> 	
> }
>
> Compilation output:
> /d837/f382.d(9): Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of type int to ubyte
>
> I'm just crazy about it! How could it happen?!

I just should forget about all integer type except *int*, because it make my head just explode!!!

Uranuz:

> 	ubyte a = 15;
> 	ubyte b = 10;
> 	
> 	ubyte c = a + b; //What is happening there?! AAAAARGH! Are you joking?!

In C/C++/D if you sum a types that are smaller than int, you obtain an int. D has copied C for backwards compatibility with C code.

Bye,
bearophile

> In C/C++/D if you sum a types that are smaller than int, you obtain an int. D has copied C for backwards compatibility with C code.
>
> Bye,
> bearophile

Is there any reasoning why this should remain unchainged? How could it break interface between languages? And also this code succesfully compiles and runs in C++.

#include <iostream>

using namespace std;

int main()
{
   unsigned short a = 15;
   unsigned short b = 10;

   unsigned short c = a + b;  //There is no problem

   cout << c << endl;

   return 0;
}

As D compiler doesn't need to compile C programme and have compatible operations with types. Why we still should keep this garbage?!

I don't know the right solution but I believe that previous example illustrates some contradiction in integer types system design or implementation.

Why we dont promote *ulong* and *long* to int? Let's also promote string into array of ints?! Can't believe it!