www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Return type overloading

reply Marti <sip email.ee> writes:
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
Jun 14 2004
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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. :(
Jun 14 2004
prev sibling next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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
Jun 14 2004
parent "Walter" <newshound digitalmars.com> writes:
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
Jun 27 2004
prev sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Jun 14 2004