Support for "var" declared return type in local functions

[gafter]

The current prototype for local functions has an incomplete implementation of support for an inferred return type.

It should either be fully specified and implemented, or the support should be removed and left for a possible future revision.

[gafter]

This and #5173 have some unfortunate interactions. It is much simpler to do one or the other.

[ldematte]

I see this is marked "Up for Grabs". I'd like to give it a go; as this is my first contribution, I was looking at something non-trivial but rather contained. Any advice/thoughts?

[gafter]

@ldematte I suggest you see how a return type is inferred for a lambda expression. The same techniques should be usable with local functions. It means that the local function body will have to be bound more than once - once to infer the return type, and once to bind the body with the return type known.

However, I believe we are more likely to want to do #5173, and the two features conflict with one another. I don't believe it is reasonable to have both in the language.

[ldematte]

Thank you for your comment, @gafter.
So, if I understood it correctly, you are suggesting that I look into something else (#5173, perhaps?), because this one will likely not make into the language?

[gafter]

@ldematte Yes, that's right. We want #5173, but we don't have anyone assigned to do that work right now.

[ldematte]

If you don't mind, I would like to give it a shot. It'd be my first contribution to Roslyn, but I have worked on compilers before, so I should be able to tackle it (in due time - if you need it quickly, I can pass)

[gafter]

@ldematte I'm not sure #5173 is a good candidate - we haven't yet worked out the specification for how exactly that should work (for example, if I call local function A and then local function B, and the former assigns to a local variable that is read by the latter, is that supposed to be allowed by the rules for definite assignment?) We have some language design work still to go, and then there is going to be a fair amount of algorithm design needed for that one. Also it has a clock that is ticking, since the local function feature has already been checked in to our future branch... Do any of (#357 #262 #158) look interesting to you? The first is a big one but self-contained, and the other two are smallish.

[ldematte]

I finally had some time to review them (you guys write a lot, awesome!) and I like #357 very much! It is quite well defined, specified and contained. I suppose it will be implemented with the hide(new)/override + bridge, plus attribute copy, plus the "at most a single intermediate method at runtime" optimization (not with the custom attribute).
How should I start? From the spec and tests, maybe? (sorry, very first time contributing here...)

[gafter]

@ldematte lets move the discussion to #357