View mode: basic / threaded / horizontal-split · Log in · Help
June 14, 2004
Return type overloading
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
June 14, 2004
Re: Return type overloading
"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. :(
June 14, 2004
Re: Return type overloading
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
June 14, 2004
Re: Return type overloading
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
June 28, 2004
Re: Return type overloading
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
>
Top | Discussion index | About this forum | D home