Hello.

Consider following snipet

module test;

int main ( char [] [] args )
{
int a = -1;
uint b = 36;
assert(a < b);

return 0;
}

The code above compiles ok, but has assertion failture at runtime. If I replace assert with

assert(cast(int)a < cast(int)b);

no exception will be thrown.

Is it normaly? I think not, if compiler decides to implicitly cast both arguments to uint hard-find bugs are appear. So I think compiler must cast arguments in this case to int's or report an error.

PS: I know, I plague all with my bugs, but c'est la vie :)

nail wrote:

> int a = -1;
> uint b = 36;
> assert(a < b);

> Is it normaly? I think not, if compiler decides to implicitly cast both
> arguments to uint hard-find bugs are appear. So I think compiler must cast
> arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec:

http://www.digitalmars.com/d/type.html:
>    5.  Else the integer promotions are done on each operand, followed by:
>          1. If both are the same type, no more conversions are done.
>          2. If both are signed or both are unsigned, the smaller type is converted to the larger.
>          3. If the signed type is larger than the unsigned type, the unsigned type is converted to the signed type.
>          4. The signed type is converted to the unsigned type. 

I think subclause 4. is what happened to your assert.

--anders

In article <cu77as$vm3$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>nail wrote:
>
>> int a = -1;
>> uint b = 36;
>> assert(a < b);
>
>> Is it normaly? I think not, if compiler decides to implicitly cast both arguments to uint hard-find bugs are appear. So I think compiler must cast arguments in this case to int's or report an error.
>
>I think it's "normal", or at least according to spec:
>
>http://www.digitalmars.com/d/type.html:
>>    5.  Else the integer promotions are done on each operand, followed by:
>>          1. If both are the same type, no more conversions are done.
>>          2. If both are signed or both are unsigned, the smaller type is converted to the larger.
>>          3. If the signed type is larger than the unsigned type, the unsigned type is converted to the signed type.
>>          4. The signed type is converted to the unsigned type.
>
>I think subclause 4. is what happened to your assert.
>

Thanx, but is this logically? This can be the reason of bugs. In C++ there is warning "signed/unsigned mismatch", I think the same should be in D but as error.

"nail" <nail_member@pathlink.com> wrote in message news:cu7nsp$1un3$1@digitaldaemon.com...
> Thanx, but is this logically? This can be the reason of bugs. In C++ there
is
> warning "signed/unsigned mismatch", I think the same should be in D but as error.

It matches the standard conforming behavior of C and C++.

"nail" <nail_member@pathlink.com> wrote in message news:cu7nsp$1un3$1@digitaldaemon.com...
> In article <cu77as$vm3$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>
>>nail wrote:
>>
>>> int a = -1;
>>> uint b = 36;
>>> assert(a < b);
>>
>>> Is it normaly? I think not, if compiler decides to implicitly cast
>>> both
>>> arguments to uint hard-find bugs are appear. So I think compiler
>>> must cast
>>> arguments in this case to int's or report an error.
>>
>>I think it's "normal", or at least according to spec:
>>
>>http://www.digitalmars.com/d/type.html:
>>>    5.  Else the integer promotions are done on each operand,
>>> followed by:
>>>          1. If both are the same type, no more conversions are done.
>>>          2. If both are signed or both are unsigned, the smaller
>>> type is converted to the larger.
>>>          3. If the signed type is larger than the unsigned type, the
>>> unsigned type is converted to the signed type.
>>>          4. The signed type is converted to the unsigned type.
>>
>>I think subclause 4. is what happened to your assert.
>>
>
> Thanx, but is this logically? This can be the reason of bugs. In C++
> there is
> warning "signed/unsigned mismatch", I think the same should be in D
> but as
> error.

Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(

Matthew wrote:
> "nail" <nail_member@pathlink.com> wrote in message news:cu7nsp$1un3$1@digitaldaemon.com...
> 
>>In article <cu77as$vm3$1@digitaldaemon.com>,
>>=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>
>>>nail wrote:
>>>
>>>
>>>>int a = -1;
>>>>uint b = 36;
>>>>assert(a < b);
>>>
>>>>Is it normaly? I think not, if compiler decides to implicitly cast both
>>>>arguments to uint hard-find bugs are appear. So I think compiler must cast
>>>>arguments in this case to int's or report an error.
>>>
>>>I think it's "normal", or at least according to spec:
>>>
>>>http://www.digitalmars.com/d/type.html:
>>>
>>>>   5.  Else the integer promotions are done on each operand, 
>>>>followed by:
>>>>         1. If both are the same type, no more conversions are done.
>>>>         2. If both are signed or both are unsigned, the smaller 
>>>>type is converted to the larger.
>>>>         3. If the signed type is larger than the unsigned type, the 
>>>>unsigned type is converted to the signed type.
>>>>         4. The signed type is converted to the unsigned type.
>>>
>>>I think subclause 4. is what happened to your assert.
>>>
>>
>>Thanx, but is this logically? This can be the reason of bugs. In C++ there is
>>warning "signed/unsigned mismatch", I think the same should be in D but as
>>error.
> 
> 
> Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-( 

I wouldn't mind this being made to an error.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4210EE43.90003@nospam.org...
>
>
> Matthew wrote:
>> "nail" <nail_member@pathlink.com> wrote in message news:cu7nsp$1un3$1@digitaldaemon.com...
>>
>>>In article <cu77as$vm3$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>>
>>>>nail wrote:
>>>>
>>>>
>>>>>int a = -1;
>>>>>uint b = 36;
>>>>>assert(a < b);
>>>>
>>>>>Is it normaly? I think not, if compiler decides to implicitly cast
>>>>>both
>>>>>arguments to uint hard-find bugs are appear. So I think compiler
>>>>>must cast
>>>>>arguments in this case to int's or report an error.
>>>>
>>>>I think it's "normal", or at least according to spec:
>>>>
>>>>http://www.digitalmars.com/d/type.html:
>>>>
>>>>>   5.  Else the integer promotions are done on each operand,
>>>>> followed by:
>>>>>         1. If both are the same type, no more conversions are
>>>>> done.
>>>>>         2. If both are signed or both are unsigned, the smaller
>>>>> type is converted to the larger.
>>>>>         3. If the signed type is larger than the unsigned type,
>>>>> the unsigned type is converted to the signed type.
>>>>>         4. The signed type is converted to the unsigned type.
>>>>
>>>>I think subclause 4. is what happened to your assert.
>>>>
>>>
>>>Thanx, but is this logically? This can be the reason of bugs. In C++
>>>there is
>>>warning "signed/unsigned mismatch", I think the same should be in D
>>>but as
>>>error.
>>
>>
>> Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(
>
> I wouldn't mind this being made to an error.

Well, that's precisely the point I was lamely making. I know Walter predicts that if we do so, it will cause myriad irritations, where 'reasonable' code is made 'unreasonable'.

IMO, dmd should have, at this pre-1.0 stage, options for switching such things into warnings, so people can get a feel for whether this prediction is true.

I have to say that, since I always make warnings max and treated as errors in C++, I don't spend hours and hours each day putting in 'silly' casts, so I doubt his prediction. But until we can try it, how can anyone know ... ??

It should be noted that while the compiler will silently convert between, say, uint and int, it halts with an error if you present an int[] unto a uint[] argument. There's a troubling lack of symmetry to all this, frankly.

- Kris


In article <cuqvuj$1nl5$1@digitaldaemon.com>, Matthew says...
>
>
>"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4210EE43.90003@nospam.org...
>>
>>
>> Matthew wrote:
>>> "nail" <nail_member@pathlink.com> wrote in message news:cu7nsp$1un3$1@digitaldaemon.com...
>>>
>>>>In article <cu77as$vm3$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>>>
>>>>>nail wrote:
>>>>>
>>>>>
>>>>>>int a = -1;
>>>>>>uint b = 36;
>>>>>>assert(a < b);
>>>>>
>>>>>>Is it normaly? I think not, if compiler decides to implicitly cast
>>>>>>both
>>>>>>arguments to uint hard-find bugs are appear. So I think compiler
>>>>>>must cast
>>>>>>arguments in this case to int's or report an error.
>>>>>
>>>>>I think it's "normal", or at least according to spec:
>>>>>
>>>>>http://www.digitalmars.com/d/type.html:
>>>>>
>>>>>>   5.  Else the integer promotions are done on each operand,
>>>>>> followed by:
>>>>>>         1. If both are the same type, no more conversions are
>>>>>> done.
>>>>>>         2. If both are signed or both are unsigned, the smaller
>>>>>> type is converted to the larger.
>>>>>>         3. If the signed type is larger than the unsigned type,
>>>>>> the unsigned type is converted to the signed type.
>>>>>>         4. The signed type is converted to the unsigned type.
>>>>>
>>>>>I think subclause 4. is what happened to your assert.
>>>>>
>>>>
>>>>Thanx, but is this logically? This can be the reason of bugs. In C++
>>>>there is
>>>>warning "signed/unsigned mismatch", I think the same should be in D
>>>>but as
>>>>error.
>>>
>>>
>>> Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(
>>
>> I wouldn't mind this being made to an error.
>
>Well, that's precisely the point I was lamely making. I know Walter predicts that if we do so, it will cause myriad irritations, where 'reasonable' code is made 'unreasonable'.
>
>IMO, dmd should have, at this pre-1.0 stage, options for switching such things into warnings, so people can get a feel for whether this prediction is true.
>
>I have to say that, since I always make warnings max and treated as errors in C++, I don't spend hours and hours each day putting in 'silly' casts, so I doubt his prediction. But until we can try it, how can anyone know ... ??
>
>

Agreed (at least on that point)

"Kris" <Kris_member@pathlink.com> wrote in message news:cus5i7$2qjh$1@digitaldaemon.com...
> It should be noted that while the compiler will silently convert
> between, say,
> uint and int, it halts with an error if you present an int[] unto a
> uint[]
> argument. There's a troubling lack of symmetry to all this, frankly.
>
> - Kris
>
>
> In article <cuqvuj$1nl5$1@digitaldaemon.com>, Matthew says...
>>
>>
>>"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4210EE43.90003@nospam.org...
>>>
>>>
>>> Matthew wrote:
>>>> "nail" <nail_member@pathlink.com> wrote in message news:cu7nsp$1un3$1@digitaldaemon.com...
>>>>
>>>>>In article <cu77as$vm3$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>>>>
>>>>>>nail wrote:
>>>>>>
>>>>>>
>>>>>>>int a = -1;
>>>>>>>uint b = 36;
>>>>>>>assert(a < b);
>>>>>>
>>>>>>>Is it normaly? I think not, if compiler decides to implicitly
>>>>>>>cast
>>>>>>>both
>>>>>>>arguments to uint hard-find bugs are appear. So I think compiler
>>>>>>>must cast
>>>>>>>arguments in this case to int's or report an error.
>>>>>>
>>>>>>I think it's "normal", or at least according to spec:
>>>>>>
>>>>>>http://www.digitalmars.com/d/type.html:
>>>>>>
>>>>>>>   5.  Else the integer promotions are done on each operand,
>>>>>>> followed by:
>>>>>>>         1. If both are the same type, no more conversions are
>>>>>>> done.
>>>>>>>         2. If both are signed or both are unsigned, the smaller
>>>>>>> type is converted to the larger.
>>>>>>>         3. If the signed type is larger than the unsigned type,
>>>>>>> the unsigned type is converted to the signed type.
>>>>>>>         4. The signed type is converted to the unsigned type.
>>>>>>
>>>>>>I think subclause 4. is what happened to your assert.
>>>>>>
>>>>>
>>>>>Thanx, but is this logically? This can be the reason of bugs. In
>>>>>C++
>>>>>there is
>>>>>warning "signed/unsigned mismatch", I think the same should be in D
>>>>>but as
>>>>>error.
>>>>
>>>>
>>>> Well, D doesn't like warnings. I agree that this is problematic,
>>>> but
>>>> D doesn't like warnings. :-(
>>>
>>> I wouldn't mind this being made to an error.
>>
>>Well, that's precisely the point I was lamely making. I know Walter predicts that if we do so, it will cause myriad irritations, where 'reasonable' code is made 'unreasonable'.
>>
>>IMO, dmd should have, at this pre-1.0 stage, options for switching
>>such
>>things into warnings, so people can get a feel for whether this
>>prediction is true.
>>
>>I have to say that, since I always make warnings max and treated as
>>errors in C++, I don't spend hours and hours each day putting in
>>'silly'
>>casts, so I doubt his prediction. But until we can try it, how can
>>anyone know ... ??
>>
>>
>
>