var return for local functions

[MkazemAkhgary]

allow var return for local functions.

var Func() => (3, 3, 4, 44); // and many other examples.

The benefits and drawbacks of having var return is same as the way having it with local variables.

[HaloFour]

dotnet/roslyn#5168

Sounds like it could be supported but only in very limited scenarios, e.g. single expression functions that don't invoke other inferred local functions or themselves.

[MkazemAkhgary]

@HaloFour for recursive functions return type could be still inferred.

var Fibonacci(int order)
{
    if(order > 0) return Fibonacci(order-1) + Fibonacci(order - 2);
    else if (order == 0) return 1;
    else return 0;
}

return type is not inferred from recursive call. its inferred from value that returns.

if there is infinite recursion I guess void suits as return type.

var ThrowSO()
{
    ThrowSO(); // void allowed by compiler
    return ThrowSO() + 1; // return type is int.
    return ThrowSO(); // type cant be inferred. compile time error
}

error will be pretty much like when you have no assignment on var. (or it could be treated as void and you cant return value in void method so that will be the error.)

var x; // invalid

having nested local functions would make it a little complicated though. I couldn't think of any method where type cant be inferred except again using recursive calls in a way that doesn't define return type.

if that's big deal use of var could be prevented in nested local functions.

Another interesting thing where return type could be multiple things, how that will be handled? I guess compiler can infer type like the way it does for ternary operator ?:.

return x ? 1 : 3.0; // return will be double.
//...
if(x) return 1;
if(y) return 2;
if(z) return null; // error there is no implicit conversion between int and null.
// providing a cast will make it work
if(z) return (int?)null; // or default(int?)

if there are two derived classes and base class, one of values returned must be cast too base class. just like the way ternary operator works.

class Foo : Base {}
class Bar : Base {}
//...
if(x) return foo;
else return bar; // error, there is no implicit conversion between foo and bar.
// casting one of them to Base should make it work.

[HaloFour]

@MkazemAkhgary

I think the bigger problem comes from "forward referencing" which is the feature that allowed local functions to be recursive to begin with. Because a local function is "hoisted" to a top-level scope it can invoke any other local function that hasn't even been declared yet. That would cause inference to go into a kind of loop where it would be impossible to determine the type. A simple pathological example might be:

public void M() {
    var Foo() => return Bar();
    var Bar() => return Foo();
}

IIRC this is even the case for recursive functions like Fibonacci since it returns the result of itself but it has no idea what it returns yet.

Anywho, I just wanted to reference the existing discussion on the subject. The support for an inferred return type is certainly on the radar and probably was expected to be part of the original implementation but other features like "forward referencing", to enable recursion, made it "complex" and so they punted it out into the future.

[MgSam]

Seems like in cases where its impossible to infer the return type the compiler could simply make it an error, as it does when overload resolution is ambiguous.

[Thaina]

#249
#888

[vladd]

I assume the problem here is with compilation phase ordering. As of now, in order to detect types if expressions within a method, we need to know the return types of all methods in advance. With this proposal, we would however need to postpone return type determination to the phase after compiling the method body.

The problem seems to be the same as the known case about var on fields.