integer division with float result

[0ffh]

Bruce Adams wrote:
> Bill Baxter Wrote:
>> Stas Sergeev wrote:
>>> Hi. [...] So the question is: how does D handle that? Was it
>>> infected by the Cish way of handling an integer division (if so -
>>> why?), or managed to get rid of that legacy thingy?

It's a legacy think, yup! But not everything that is old is bad...
the rules didn't evolve like that for no reason.

>> Comparing with dynamically typed languages like Python isn't useful 
>> because in Python a/2 can return an integer for if a==4 a float if
>> a==5. A statically typed language like D doesn't have that luxury.
>> 
>> Anyway, that said, I think it'd be nice to have / do float division,
>> and introduce another operator (like python's //) for truncated
>> integer division.  But I think Walter is too entrenched in C-ish ways
>> to see any value in changing how it works.  Python is changing because
>> it wants to be newbie/scientist friendly above all else.  D merely
>> wants to be easier to use than C++.  There's a lot of territory
>> between "newbie-friendy" and "easier than C++".  In particular "has
>> pointers" and "newbie-friendly" tend to keep their distance from one
>> another.
>> 
>> --bb
> 
> Here's another (non-D?) thought. How about overloading on the return
> type? In a strongly typed language its only convention that makes the
> return type somehow special. I believe the original reason for return
> values being special may have been that they are the only things left on
> the stack when returning from a function call. This was only true early
> on when all arguments were passed by value. We don't seem to have moved
> beyond that, we only tease around the edges with covariant returns and
> returning multiple values but semantically there's no difference
> between: [...] So why do we still insist on it in modern languages?
> 
> Regards,
> 
> Bruce.

Return type overloading is not practical, or at least not without solving a
few problems first. What return type would you expect from the function?
Okay, in an assignment it's clear.
What about function calls in expressions?
What if you have overloaded foo to return int or float, and bar to return
int or float. Then go and call bar(foo())... oooopsie! =)
And it's not always as easy as just int or float; think arbitrary types!
Okay, there are solutions to all this, but the only reasonable ones I
know need extra hints for the compiler (some kind of syntax extension,
or building a new semantic upon an available syntax).

Regards, Frank