Unlike long <-> int conversions, signed <-> unsigned conversions are narrowing in both ways. If anything, those conversions should be even more strict.
On another note, i had this thought about fundamental types. What i thought about is, making fundamental types a library solution. "What? Are you out of your mind? How're you gonna make int a library type?" The way i see it, fundamental types could be implemented as structs with lots of assembly code written in their operator overloads. The emitted binary would be exactly the same and there would be much less magic in the language. The literals for fundamental types would be interpreted as string literals, which would be parsed at compile time in their constructors. AND one would be able to make custom types akin the fundamental ones with absolutely no difference in look-and-feel or performance. since the integral literal would be translated to a string, one could be able to wrote a meter-long literal and use it with BigInt, which would no longer feel like a weird outcast in the world of integral types. The only shortcoming, that i see right now is the fact. that the implementation of fundamental types is completely defined by underlying C implementation. This could be dealt with by introducing compiler intrinsic functions for fundamental type manipulations. The only fundamental type would be void* and void[]., which would, in fact, be used to implement e.g. int and float. This would also reduce the number of magical properties, like min and max, making them all nice and visible. And yes, i know, that the compiler benefits of them being built-in and it can perform optimizations. It still can do those optimizations, because their in druntime. Besides, this is a good opportunity to improve the general optimization capabilities of the compiler. On Fri, Oct 21, 2011 at 12:01 PM, Jonathan M Davis <jmdavisp...@gmx.com> wrote: > On Friday, October 21, 2011 11:57:50 Gor Gyolchanyan wrote: >> That's because implicit casts in D are much more strict, then those in >> C/C++. Such seemingly intuitive cats, e.g. from long to int are not >> performed due to potential loss of data. >> Casting from int to uint has the same effect of potential loss of data. > > In D, integral types implicitly convert to their unsigned counterparts and > vice versa. D does not consider those conversions to be narrowing conversions > which require a cast (though they _are_ narrowing conversions and do risk > messing up the number if it's too large or too small). > > - Jonathan M Davis >