Is all this Invarient **** er... stuff, premature optimisation?
Steven Schveighoffer
schveiguy at yahoo.com
Tue Apr 29 07:05:43 PDT 2008
"e-t172" wrote
> Lionello Lunesu a écrit :
>>
>> "Walter Bright" wrote in message
>>> Me Here wrote:
>>>> Janice Caron wrote:
>>>>> Functions don't overload on return value.
>>>> They don't? Why not? Seems like a pretty obvious step to me.
>>>
>>> Type inference in D is done "bottom up". Doing overloading based on
>>> function return type is "top down". Trying to get both schemes to
>>> coexist is a hard problem.
>>
>> But a function's result can be overloaded using "out", so why can't it be
>> overloaded using the return value?
>>
>> Can't the compiler treat a return value as an implicit out argument?
>
> Consider this:
>
> int foo();
> float foo();
>
> void bar(int a);
> void bar(float a);
>
> Then this:
>
> void main()
> {
> bar(foo());
> }
>
> There is an obvious problem here.
Yes, one that is solved like any other that has ambiguity: casting. We will
have the same problem when opImplicitCast is introduced.
This seems like a rare case anyways, not a reason not to have overloaded
return values.
-Steve
More information about the Digitalmars-d
mailing list