Steven Schveighoffer Wrote:

> 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?
> 
> void foo(int x, int y)

Well, I said "real-world example". You're talking about frequency, right? If the frequency is zero, it's no problem.

Andrej Mitrovic 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.
> 
> Where's those lint tools for D.. :/

It is indeed a common bug. I made a proposal for fixing it, which was accepted, but I still haven't got around to making the patch. It's a simple addition to range propagation: integer operations need to record if there is a potentially non-zero fractional part in the result.
Non-zero fractional parts are created by /, %, and ^^.
Certain operations (bitwise operations, casts) force the fractional part to zero, enabling it to be convertable to float.

Am 09.07.2011, 00:45 Uhr, schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> 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.. :/

That's why Pascal uses another set of operators for integer divisions, namely 'div' and 'mod', so you can never get into that situation. The above code would have worked and in case step was an integer, the compiler would have complained about not using 'div'. I doubt that we will see these in D - at the end of the day code that is both valid C and valid D must do the same thing, but I never had problems with 'div' and 'mod' and it seems like a good solution.

Marco Leise:

> That's why Pascal uses another set of operators for integer divisions, namely 'div' and 'mod', so you can never get into that situation. The above code would have worked and in case step was an integer, the compiler would have complained about not using 'div'. I doubt that we will see these in D - at the end of the day code that is both valid C and valid D must do the same thing, but I never had problems with 'div' and 'mod' and it seems like a good solution.

On this I like the Pascal design better. I think in D2 you can't change how division works. Python2 has done this during its evolution to Python3, but D has to keep some compatibility with C.

But adding an integer division operator to D and later discouraging (with a warning too) the usage of the normal division operator for integer numbers is a possibility (later if you want to port C code to D you see many deprecation integer division warnings. A hypothetical c2d tool based on DMD source is later able to fix your C code ported to D).

Bye,
bearophile