Has function return type overloading been considered for D? It might be useful for some scenarios.

For example, in the code::

int get2()
{
return 2;
}
float get2()
{
return 2.0;
}

the function body that gets called depends on the expected type of the value::

int i;
float f;

i = get2(); //the int version body of get2() is called
f = get2(); //the float version is called
f = cast(int)get2(); //the int version is called, and the value is implicitly
//casted to a float
f = cast(float)cast(int)get2(); //the int version is called, and the value is
//explicitly casted to a float

I'm not sure about what to do if the expected type can't be determined. Perhaps we should require an explicit cast? Consider this::

f = 2 + get2();

I'm sure there are loads of other ambiguities I haven't thought about. I'm not even sure if it's a good idea, but it's an idea worth considering nevertheless.

--
Marti

"Marti" <sip@email.ee> wrote in message news:cajkkr$30sr$1@digitaldaemon.com...
> Has function return type overloading been considered for D? It might be useful for some scenarios.
>
> For example, in the code::
>
> int get2()
> {
> return 2;
> }
> float get2()
> {
> return 2.0;
> }
>
> the function body that gets called depends on the expected type of the value::
>
> int i;
> float f;
>
> i = get2(); //the int version body of get2() is called
> f = get2(); //the float version is called
> f = cast(int)get2(); //the int version is called, and the value is implicitly
> //casted to a float
> f = cast(float)cast(int)get2(); //the int version is called, and the value is
> //explicitly casted to a float
>
> I'm not sure about what to do if the expected type can't be determined. Perhaps we should require an explicit cast? Consider this::
>
> f = 2 + get2();
>
> I'm sure there are loads of other ambiguities I haven't thought about. I'm not even sure if it's a good idea, but it's an idea worth considering nevertheless.

It's something that crops up again and again, in various languages. There are limited circumstances in which it's both unambiguous and desirable. However, it's the edge cases that get you - templates and mixins would make this really hideous. Gives me shudders thinking about it. :(

In other languages (like in O'Caml) this makes perfect sense, but in languages derived from C, it goes absolutely contrary to the philosophy of the language: every expressions has a definite type which can be derived from without knowledge of the context, only looking at the type of the used symbols.

Unfortunately, there already is one exception to this rule, which is: function pointers/delegates. If you have overloaded functions, you need the context of the expression to know which one to pick. But that is another story.



Marti wrote:

> Has function return type overloading been considered for D? It might be useful for some scenarios.
> 
> For example, in the code::
> 
> int get2()
> {
> return 2;
> }
> float get2()
> {
> return 2.0;
> }
> 
> the function body that gets called depends on the expected type of the value::
> 
> int i;
> float f;
> 
> i = get2(); //the int version body of get2() is called
> f = get2(); //the float version is called
> f = cast(int)get2(); //the int version is called, and the value is
> implicitly //casted to a float
> f = cast(float)cast(int)get2(); //the int version is called, and the value
> is //explicitly casted to a float
> 
> I'm not sure about what to do if the expected type can't be determined. Perhaps we should require an explicit cast? Consider this::
> 
> f = 2 + get2();
> 
> I'm sure there are loads of other ambiguities I haven't thought about. I'm not even sure if it's a good idea, but it's an idea worth considering nevertheless.
> 
> --
> Marti

Marti wrote:

> Has function return type overloading been considered for D? It might be useful
> for some scenarios.
> 
> For example, in the code::
> 
> int get2()
> {
> return 2;
> }
> float get2()
> {
> return 2.0;
> }
> 
> the function body that gets called depends on the expected type of the value::
> 
> int i;
> float f;
> 
> i = get2(); //the int version body of get2() is called
> f = get2(); //the float version is called
> f = cast(int)get2(); //the int version is called, and the value is implicitly
> //casted to a float
> f = cast(float)cast(int)get2(); //the int version is called, and the value is
> //explicitly casted to a float
> 
> I'm not sure about what to do if the expected type can't be determined. Perhaps
> we should require an explicit cast? Consider this::
> 
> f = 2 + get2();
> 
> I'm sure there are loads of other ambiguities I haven't thought about. I'm not
> even sure if it's a good idea, but it's an idea worth considering nevertheless.
> 
> --
> Marti

You can use out arguments to simulate this, and in general get more expressive and complex returns. ie:

void get2(out int result)
{
	result = 2;
}

void get2(out float result)
{
	result = 2.0;
}

Cheers,
Sigbjørn Lund Olsen

D (as well as C and C++) fundamentally determines type by "bottom up" semantic analysis. You're right about the function pointers being a kludge for this. The language can stand one such kludge, but more than one and the types become indeterminate.

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:cajoer$3p7$2@digitaldaemon.com...
> In other languages (like in O'Caml) this makes perfect sense, but in languages derived from C, it goes absolutely contrary to the philosophy of the language: every expressions has a definite type which can be derived from without knowledge of the context, only looking at the type of the
used
> symbols.
>
> Unfortunately, there already is one exception to this rule, which is: function pointers/delegates. If you have overloaded functions, you need
the
> context of the expression to know which one to pick. But that is another story.
>
>
>
> Marti wrote:
>
> > Has function return type overloading been considered for D? It might be useful for some scenarios.
> >
> > For example, in the code::
> >
> > int get2()
> > {
> > return 2;
> > }
> > float get2()
> > {
> > return 2.0;
> > }
> >
> > the function body that gets called depends on the expected type of the value::
> >
> > int i;
> > float f;
> >
> > i = get2(); //the int version body of get2() is called
> > f = get2(); //the float version is called
> > f = cast(int)get2(); //the int version is called, and the value is
> > implicitly //casted to a float
> > f = cast(float)cast(int)get2(); //the int version is called, and the
value
> > is //explicitly casted to a float
> >
> > I'm not sure about what to do if the expected type can't be determined. Perhaps we should require an explicit cast? Consider this::
> >
> > f = 2 + get2();
> >
> > I'm sure there are loads of other ambiguities I haven't thought about.
I'm
> > not even sure if it's a good idea, but it's an idea worth considering nevertheless.
> >
> > --
> > Marti
>