[Proposal] Variable declarations at yield return

[bondsbw]

This proposal is to allow variable declarations at the site of yield return:

public IEnumerable<int> Fibonacci()
{
    yield return var last = 0;
    yield return var current = 1;

    while(true)
    {
        yield return var temp = current + last;
        last = current;
        current = temp;
    }
}

The closest I can do right now is to define the variables before the yield return:

public IEnumerable<int> Fibonacci()
{
    int last;
    int current;

    yield return last = 0;
    yield return current = 1;

    while(true)
    {
        int temp;

        yield return temp = current + last;
        last = current;
        current = temp;
    }
}

The current syntax isn't as useful. I can't use var to declare the variables, so I might as well initialize them on the same line they are being declared.

[mburbea]

Compound assignment with a control statement is anything but obvious, but outside of terseness of code what is the benefit?
Currently you can't do this:
if((var x=someFunc())!=5)
nor can you do:
return var x=5
Why should yield return be given this special behavior?

[bondsbw]

@mburbea

return var x=5; doesn't really make sense. The method returns and the variable cannot be used beyond that point.

OTOH, the variable may still be useful after yield return var x=5;.

[bondsbw]

Also I believe the if((var x=someFunc())!=5) syntax is covered by issue #254, Declaration Expressions. (It was also discussed on the Codeplex forum: https://roslyn.codeplex.com/discussions/565640).

Actually now that I think about it, the yield return var x=5; syntax could simply be a specific case of declaration expressions.

[whoisj]

While I see how this saves a small amount of typing, I feel like this is really makes the code more difficult to read. Is there some benefit besides saving a few key strokes?

[svick]

I can't use var to declare the variables, so I might as well initialize them on the same line they are being declared.

Is there any reason why you wouldn't want to do that? I.e.:

var temp = current + last;
yield return temp;

[bondsbw]

Consider this scenario:

public IEnumerable<string> HelloWorld()
{
    yield return "Hello";
    yield return "World";
}

Say I want to add a bit of logging:

public IEnumerable<string> HelloWorld()
{   
    var h = "Hello";    
    yield return h;
    Console.WriteLine(h);

    var w = "World";
    yield return w;
    Console.WriteLine(w);
}

Now the strings are being created separately from the yield return. This proposal would allow:

public IEnumerable<string> HelloWorld()
{
    yield return var h = "Hello";
    Console.WriteLine(h);

    yield return var w = "World";
    Console.WriteLine(w);
}

This flow is more consistent with the original, where the strings are created at the site of the yield return.

[bondsbw]

I've obviously used very simplistic code in these examples. Real world examples are much more complicated, so the solution has a bigger impact.

[HaloFour]

@bondsbw Your scenario doesn't make much sense. You wouldn't be logging the yielded value until/unless the consumer attempted to move to the next value. You'd want to capture the result to a variable, log it, and then yield it, potentially with a helper method to do most of that.

Beyond that I think that this conversation is and should be wrapped up with the proposal for declaration expressions as that is effectively what it is.

[bondsbw]

@HaloFour It was just a very simplistic example. Nitpicking the usefulness of the parts of the code that aren't related to the proposal is not helpful.

But I agree that declaration expressions would (should) provide this, so I'll close this issue.