Implicit conversion rules

[Sigg via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 19:07:24 UTC, anonymous wrote:

> The problem is of course that int and ulong have no common 
> super type, at least not in the primitive integer types. int 
> supports negative values, ulong supports values greater than 
> long.max.

Yes, I'm well aware of that. I was under the (wrongful)impression 
that auto was doing much more under the hood and that it was more 
safety oriented, I've prolly mixed it with something else while 
reading some article.

> As far as I understand, you'd like the compiler to see the 
> values of `a` and `b` (-10, 0), figure out that the result is 
> negative, and then make `c` signed based on that. That's not 
> how D rolls. The same code must compile when the values in `a` 
> and `b` come from run time input. So the type of the addition 
> cannot depend on the values of the operands, only on their 
> types.
>
> Or maybe you'd expect an `auto` variable to be able to hold 
> both negative and very large values? But `auto` is not a 
> special type, it's just a shorthand for typeof(right-hand 
> side). That means, `auto` variables still get one specific 
> static type, like int or ulong.

Ima clarify what I expected using my previous example:

     ulong a = 0;
     int b = -10;
     auto c = a + b;

a gets cast to narrowest primitive type that can hold its value, 
in this case bool since bool can hold 0 value resulting in c 
having value of -10. If a was bigger than max long I'd expect an 
error/exception. Now on the other hand I can see why something 
like this would not be implemented since it would ignore implicit 
conversion table and prolly cause at least few more "fun" side 
effects.

> std.bigint and core.checkedint may be of interest to you, if 
> you prefer safer operations over faster ones.
>
> http://dlang.org/phobos/std_bigint.html 
> http://dlang.org/phobos/core_checkedint.html

This is exactly what I was looking for. Thanks!