Types A!1 and A!1u not considered equal?

[Gor Gyolchanyan]

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 <jmdavisProg at 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
>