integer division with float result

[Bruce Adams]

0ffh Wrote:

> Bruce Adams wrote:
> > So casting cannot be eliminated entirely that way but it can be
> > significantly reduced. That's got to be a good thing surely?
> 
> Well, the use of a cast as hint for the compiler looks like a
> rather nice choice. But then I don't quite see how it improves
> the thing about integer and float division apart from the case
> of assignments. Take:
> 
>    void foo(int);
>    void foo(float);
> 
> As it is now, I have for example
> 
>    int i,j;
>    float f;
>    [...]
>    i=i/j; // implicit int
>    f=cast(float)i/j; // explicit float
>    foo(i/j); // implicit int
>    foo(cast(float)i/j); // explicit float
> 
> With return type overloading I get
> 
>    int i,j;
>    float f;
>    [...]
>    i=i/j; // implicit int
>    f=i/j; // implicit float
>    foo(i/j); // compiler error: under-determined type information
>    foo(cast(int)i/j); // explicit int
>    foo(cast(float)i/j); // explicit float
> 
> 
> So now there are just different cases where a cast is needed.
> For some people I am sure the case with overloaded return types
> has more appeal, but for others it is different. It's just a
> matter of tastes, really, as the C way is no more complicated
> than the other way. It is just not what many people expect at
> first. I can't yet see how this small improvement is worth the
> trouble implementing.
> 
> Regards, frank

Well I wasn't advocating a change to D (yet). Hence the non D in my original post. It was more a thought experiment. Your use case above is certainly a compelling reason not to do it this way, at least for division. I wonder if there is not a way of having the best of both worlds. Still, I begin to see why others want a seperate div operator. I shall ponder some more...