integer division with float result

Bruce Adams tortoise_74 at yeah.who.co.uk
Sun Nov 18 18:03:23 PST 2007


0ffh Wrote:

> Bruce Adams wrote:
> > 
> > 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
> 
The obvious thing to do would be to require explict qualification when there is an ambiguity. For everything else the types are sufficient cues.
I suspect what is required is type inference a la ML.
So in the case of 
(in the following feel free to replace X with divde, Y with print and R with random if that makes it easier to read).

int X(int a)
long X(long b)

void Y(int y)
void Y(long y)

void Z(int y)
void Q(long y)

int a = 1;
long b = 2;

Z(X(a)) is legal (no ambiguity)
Q(X(b)) is legal (no ambiguity)

Y(X(a))  - infer use of Y(int) because X(int) because a = int
Y(X(b)) - infer use of Y(long) because X(long) because b = long

The only place you have real ambiguity is:

int R(void)
long R(void)

so X(R()) is ambiguous and should thus cause a compile error.
It must be replaced with either:

int temp = R();
X(temp)

or X(cast(int)R())

This is trivial to implement in a compiler the type inference is a little more tricky (though Walter did say he was interested in adding functional programming features to D ;-).

I think a good syntactic sugar to use for that would be named parameters, which are useful for so many other reasons (but much less trivial to implement)
So 

Y(int Int)
Y(long Long)

would allow

X(Y(Int))

unfortunately this doesn't solve the problem for R because the return type cannot be named
So casting cannot be eliminated entirely that way but it can be significantly reduced. That's got to be a good thing surely?

Regards,

Bruce.




More information about the Digitalmars-d mailing list