Detecting inadvertent use of integer division

[Don]

Bob Jones wrote:
> "Don" <nospam at nospam.com> wrote in message 
> news:hg5nkk$1n37$1 at digitalmars.com...
>> bearophile wrote:
>>> Don:
>>>>> In Pascal too (and OCaML, but the situation is different) they are 
>>>>> separated. I think here having two operators is better,
>>>> Why?
>>> You are intelligent and expert so you must know my answer, so I fear 
>>> yours is a trick question :-)
>> No, it's not a trick question. You've used Python extensively, I haven't.
>>
>>> Two operators allow to reduce the need for casts (and 
>>> rounding/truncation), and are more explicit, allowing the code to express 
>>> its meaning better to people that come after the original programmer.
>> OK. I'm trying to get most of the benefits without needing an extra 
>> operator.
> 
> Having made the switch from Delphi to C++ a few years ago I ran into this 
> alot. I dislike that I have to litter my arithmetic expresions with casts in 
> order to get the division operator to do what I want it to. And I suspect 
> all of those who are used to having seperate intdiv & fltdiv operators will 
> agree.

Your arithmetic expressions would only become "littered with casts" if 
you regularly use integer division inside floating-point expressions.
Personally, I cannot recall *ever* having intentionally used integer 
division inside a floating point expression. (I've seen inadvertent uses 
of it, plenty of times).

> So using cast(int) to mean "actualy I did intend the integer division inside 
> the following expression" instead of it's usual "convert this to" makes an 
> ugly situation even more so imo.

Well, it's really a bizarre situation. It's a very strange thing to be 
doing.

> The fact that adding a specific intdiv operator would not only avoid more 
> casting, but remove the the need for casting in a lot of existing cases 

I bet there are negligible cases where casting is required.

> should count pretty well against the "no more operator/keywords" argument. 
> Imo it should count enough to override it.
> 
> But i guess cheap&ugly is more likely to make it in than 
> expensive&expresive&ellegant.