This is just an observation, not a question or anything.

void main()
{
    enum width = 100;
    double step = 1 / width;

    writeln(step);  // 0
}

I've just had this bug in my code. I forgot to make either width or 1 a floating-point type. IOW, I didn't do this:

void main()
{
    enum width = 100.0;
    double step = 1 / width;   // or .1

    writeln(step);  // now 0.01
}

This seems like a very easy mistake to make. But I know the compiler is probably powerless to do anything about it. It has an expression resulting in an int at the RHS, and it can easily cast this to a double since there's no obvious loss of precision when casting int->double.

Where's those lint tools for D.. :/

On Fri, 08 Jul 2011 18:45:58 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> This is just an observation, not a question or anything.
>
> void main()
> {
>     enum width = 100;
>     double step = 1 / width;
>
>     writeln(step);  // 0
> }
>
> I've just had this bug in my code. I forgot to make either width or 1
> a floating-point type. IOW, I didn't do this:
>
> void main()
> {
>     enum width = 100.0;
>     double step = 1 / width;   // or .1
>
>     writeln(step);  // now 0.01
> }
>
> This seems like a very easy mistake to make. But I know the compiler
> is probably powerless to do anything about it. It has an expression
> resulting in an int at the RHS, and it can easily cast this to a
> double since there's no obvious loss of precision when casting
> int->double.

BTW, this is definitely not something the compiler can determine.  You may actually *want* to have integer division then convert to a double.

So a lint tool would be perfect for this -- it cannot be an error, and warnings don't exist in D.

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vybq4xkkeav7ka@localhost.localdomain...
> On Fri, 08 Jul 2011 18:45:58 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>> This is just an observation, not a question or anything.
>>
>> void main()
>> {
>>     enum width = 100;
>>     double step = 1 / width;
>>
>>     writeln(step);  // 0
>> }
>>
>> I've just had this bug in my code. I forgot to make either width or 1 a floating-point type. IOW, I didn't do this:
>>
>> void main()
>> {
>>     enum width = 100.0;
>>     double step = 1 / width;   // or .1
>>
>>     writeln(step);  // now 0.01
>> }
>>
>> This seems like a very easy mistake to make. But I know the compiler is probably powerless to do anything about it. It has an expression resulting in an int at the RHS, and it can easily cast this to a double since there's no obvious loss of precision when casting int->double.
>
> BTW, this is definitely not something the compiler can determine.  You may actually *want* to have integer division then convert to a double.
>
> So a lint tool would be perfect for this -- it cannot be an error, and warnings don't exist in D.
>

Yea they do: dmd -wi

On Sat, 09 Jul 2011 13:28:25 -0400, Nick Sabalausky <a@a.a> wrote:

> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
> news:op.vybq4xkkeav7ka@localhost.localdomain...
>> On Fri, 08 Jul 2011 18:45:58 -0400, Andrej Mitrovic
>> <andrej.mitrovich@gmail.com> wrote:
>>
>>> This is just an observation, not a question or anything.
>>>
>>> void main()
>>> {
>>>     enum width = 100;
>>>     double step = 1 / width;
>>>
>>>     writeln(step);  // 0
>>> }
>>>
>>> I've just had this bug in my code. I forgot to make either width or 1
>>> a floating-point type. IOW, I didn't do this:
>>>
>>> void main()
>>> {
>>>     enum width = 100.0;
>>>     double step = 1 / width;   // or .1
>>>
>>>     writeln(step);  // now 0.01
>>> }
>>>
>>> This seems like a very easy mistake to make. But I know the compiler
>>> is probably powerless to do anything about it. It has an expression
>>> resulting in an int at the RHS, and it can easily cast this to a
>>> double since there's no obvious loss of precision when casting
>>> int->double.
>>
>> BTW, this is definitely not something the compiler can determine.  You may
>> actually *want* to have integer division then convert to a double.
>>
>> So a lint tool would be perfect for this -- it cannot be an error, and
>> warnings don't exist in D.
>>
>
> Yea they do: dmd -wi

Hm... I didn't know about that switch, I thought warnings were enabled with -w and that made them errors.

I suppose you could stick this in there.

-Steve

On Monday 11 July 2011 08:17:50 Steven Schveighoffer wrote:
> On Sat, 09 Jul 2011 13:28:25 -0400, Nick Sabalausky <a@a.a> wrote:
> > "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vybq4xkkeav7ka@localhost.localdomain...
> > 
> >> On Fri, 08 Jul 2011 18:45:58 -0400, Andrej Mitrovic
> >> 
> >> <andrej.mitrovich@gmail.com> wrote:
> >>> This is just an observation, not a question or anything.
> >>> 
> >>> void main()
> >>> {
> >>> 
> >>>     enum width = 100;
> >>>     double step = 1 / width;
> >>> 
> >>>     writeln(step);  // 0
> >>> 
> >>> }
> >>> 
> >>> I've just had this bug in my code. I forgot to make either width or
> >>> 1
> >>> a floating-point type. IOW, I didn't do this:
> >>> 
> >>> void main()
> >>> {
> >>> 
> >>>     enum width = 100.0;
> >>>     double step = 1 / width;   // or .1
> >>> 
> >>>     writeln(step);  // now 0.01
> >>> 
> >>> }
> >>> 
> >>> This seems like a very easy mistake to make. But I know the compiler is probably powerless to do anything about it. It has an expression resulting in an int at the RHS, and it can easily cast this to a double since there's no obvious loss of precision when casting int->double.
> >> 
> >> BTW, this is definitely not something the compiler can determine.  You
> >> may
> >> actually *want* to have integer division then convert to a double.
> >> 
> >> So a lint tool would be perfect for this -- it cannot be an error, and warnings don't exist in D.
> > 
> > Yea they do: dmd -wi
> 
> Hm... I didn't know about that switch, I thought warnings were enabled with -w and that made them errors.
> 
> I suppose you could stick this in there.

By default, warnings are completely disabled. -w enables them and makes the errors. So, it's more like telling it to add more errors than to enable warnings. -wi enables them, but it leaves them as warnings. They're then "informational" (basically, -wi makes warnings work like they do with pretty much every other compiler on the planet). IIRC, people kept bugging Walter about how warnings work with dmd, so he added -wi.

- Jonathan M Davis

On Mon, 11 Jul 2011 11:45:47 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Monday 11 July 2011 08:17:50 Steven Schveighoffer wrote:

>>
>> Hm... I didn't know about that switch, I thought warnings were enabled
>> with -w and that made them errors.
>>
>> I suppose you could stick this in there.
>
> By default, warnings are completely disabled. -w enables them and makes the
> errors. So, it's more like telling it to add more errors than to enable
> warnings. -wi enables them, but it leaves them as warnings. They're then
> "informational" (basically, -wi makes warnings work like they do with pretty
> much every other compiler on the planet). IIRC, people kept bugging Walter
> about how warnings work with dmd, so he added -wi.

eh... then I retract my statement.  I thought the set of -wi warnings could be different than the set of -w errors.

This is not always an error, I don't think you should need a cast for things like this.

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vyge30ogeav7ka@localhost.localdomain...
> On Sat, 09 Jul 2011 13:28:25 -0400, Nick Sabalausky <a@a.a> wrote:
>
>> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vybq4xkkeav7ka@localhost.localdomain...
>>> On Fri, 08 Jul 2011 18:45:58 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>>>
>>>> This is just an observation, not a question or anything.
>>>>
>>>> void main()
>>>> {
>>>>     enum width = 100;
>>>>     double step = 1 / width;
>>>>
>>>>     writeln(step);  // 0
>>>> }
>>>>
>>>> I've just had this bug in my code. I forgot to make either width or 1 a floating-point type. IOW, I didn't do this:
>>>>
>>>> void main()
>>>> {
>>>>     enum width = 100.0;
>>>>     double step = 1 / width;   // or .1
>>>>
>>>>     writeln(step);  // now 0.01
>>>> }
>>>>
>>>> This seems like a very easy mistake to make. But I know the compiler is probably powerless to do anything about it. It has an expression resulting in an int at the RHS, and it can easily cast this to a double since there's no obvious loss of precision when casting int->double.
>>>
>>> BTW, this is definitely not something the compiler can determine.  You
>>> may
>>> actually *want* to have integer division then convert to a double.
>>>
>>> So a lint tool would be perfect for this -- it cannot be an error, and warnings don't exist in D.
>>>
>>
>> Yea they do: dmd -wi
>
> Hm... I didn't know about that switch, I thought warnings were enabled with -w and that made them errors.
>
> I suppose you could stick this in there.
>

-wi: Enable warnings
-w: Enable warnings and treat them as errors

Didn't used to have -wi, but I bugged the hell out of Walter about it. ;)

The --help screen describes -w and -wi differently than above, but the above is more accurate.

On Mon, 11 Jul 2011 16:46:07 -0400, Nick Sabalausky <a@a.a> wrote:

> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message

>>
>> Hm... I didn't know about that switch, I thought warnings were enabled
>> with -w and that made them errors.
>>
>> I suppose you could stick this in there.
>>
>
> -wi: Enable warnings
> -w: Enable warnings and treat them as errors
>
> Didn't used to have -wi, but I bugged the hell out of Walter about it. ;)
>
> The --help screen describes -w and -wi differently than above, but the above
> is more accurate.

Yes, but this is getting into territory where the false positive rate might get high.  I don't think it should be an error under -w.  So that means -wi and -w would cover different sets of warnings.

-Steve

Steven Schveighoffer Wrote:

> Yes, but this is getting into territory where the false positive rate might get high.

I bet it will be difficult to find a real-world example of this false positive.

On Tue, 12 Jul 2011 11:07:57 -0400, Kagamin <spam@here.lot> wrote:

> Steven Schveighoffer Wrote:
>
>> Yes, but this is getting into territory where the false positive rate
>> might get high.
>
> I bet it will be difficult to find a real-world example of this false positive.

It depends on how the warning is triggered.

Does this fail?

double x = 1;

Does this:

double x = 1 / 2;

How about this:

void foo(int x, int y)
in
{
   assert(y != 0);
   assert(x % y == 0);
}
body
{
  double z = x / y;
}

The reason for declaring something a double is not always because you want the thing you are assigning it to be a double expression.  For instance, sometimes I do something like this:

int z = x / y;

And then realize, all the places where I use z, I actually want to be doubles, so I simply change it to:

double z = x / y;

To avoid frequent casting.

-Steve