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