Re: Why can't overloads take into account the return type.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"Daniel O'Connell [C# MVP]" <onyxkirx@xxxxxxxxxxxxxxxxxxxxx> wrote in
message news:%23le$D74VFHA.3184@xxxxxxxxxxxxxxxxxxxxxxx
> Now, you add into that a requirement to know the type of the variable the
> return type is going to be assigned to or the parameter type it will be
> passed to. This forces the compiler to have to be able to see
>
> int x = Parse(something);

The compiler is going to need to know the return type anyway. I don't see it
much different from:

Parse(Something, ref x);

> The method call is not individually resolvable, it becomes an expression
> that means nothing concrete without being contained within another
> expression(I do not believe this issue exists *anywhere* else in the
> language, but I'm not certain). The compiler is harder to write, the
> language harder to learn. Bam, instant complexity at the base level of the
> compiler.

Overloading makes the language harder to learn, as does inheritance and
interfaces, we'd better leave those out too. :-)

> Now, lets take this a step further and produce a few difficult or
> impossible to resolve scenarios.
>
> Given:
> int Parse(string value);
> double Parse(string value);
>
> int Calc(int value);
> double Calc(double value);
>
> double d = Calc(Parse("15")):
>
> When the compiler takes a look at the call to Parse it cannot resolve what
> overload to call. The compile rmust then take a look at the parameter type
> for Calc, which also cannot be resolved atomicall ywithout knowing the
> resolved return type of the Parse call, so you have yet another unresolved
> method. You step back a little farther and finally discover an assignment
> meaning you can determine the desired return type of Calc, and in this
> example, determine which overload of Parse must be called. However,
> considering the compiler without return type overloads would have had no
> trouble doing this, what is the cost in complexity?

But it can do it and it makes sense to the programmer for it to be double
all the way through.

> Is this really as simple as you think it is? I've not even started on the
> possible issues with generics and anonymous methods and the language
> itself is already considerably more complex. Realistically implementing
> return type overloading, IMHO, requires a mechanism to manually select the
> override instead of relying on automatic selection that ignores casts and
> converstions.

I'm sure it can get complex but in any case it can't resolve the call it
should just say so. Programmers would know to specify the return type in the
necessary cases. Maybe something like double d = Calc((double)Parse("15")):
could be used.

>
>


.

Relevant Pages

  • Re: Why cant overloads take into account the return type.
    ... > The compiler is going to need to know the return type anyway. ... its utility verse complexity. ... type overloading provides minimal utliity with significant complexity. ... > I'm sure it can get complex but in any case it can't resolve the call it ...
    (microsoft.public.dotnet.languages.csharp)
  • OO and information oriented programming (was Re: Simple Parser)
    ... >> If you're developing a compiler for a language for the first time, ... >> the grammar you're using does what you want, ... Computers don't just process for the sake of it. ... reducing complexity, a task at the core of software development. ...
    (comp.programming)
  • Re: Hiding the value of Constants
    ... about overloading named objects should be different for functions. ... local variable X of type Boolean, the compiler wouldn't catch this. ... you used the wrong parameter type, for example; and since subprograms ... The programming style has ...
    (comp.lang.ada)
  • Re: OO and information oriented programming (was Re: Simple Parser)
    ... > The parse tree tells the developer a lot about the behaviour of a part of ... The first version of the Basic compiler for my book "Design Your Own ... > Computers don't just process for the sake of it. ... > reducing complexity, a task at the core of software development. ...
    (comp.programming)
  • Re: Python and Flaming Thunder
    ... the compiler optimizes it away, ... I think overloading your catch error types to include objects ... assignment could throw an error) makes things confusing. ...
    (comp.lang.python)