Allow to mix return and yield return in certain conditions

[karakasa]

I think it can be beneficial if return is allowed to be mixed with yield return if return is before all yields, to enable shortcuts.

I searched in the discussions and no one seemed to bring this up.

For example:

public IEnumerable<int> DoSomething(this IEnumerable<int> src)
{
    if (src is int[] srcArray)
        return DoSomethingArray(srcArray);

    // Fallback
    yield return src.First();
}

private IEnumerable<int> DoSomethingArray(int[] src)
{
    return new int[]{ src[0] };
}

Though I acknowledge that the feature can be very challenging to implement, if allowed to be combined with try...catch, complex control fows, etc.

[ufcpp]

#378
#815
#5033
#5066

[karakasa]

Yield return a collection will involve new syntaxes. Besides it may lead to extra allocation, if the compiler cannot optimize it away.

Say we use yield return!, for instance:

public IEnumerable<int> DoSomething(this IEnumerable<int> src)
{
    if (src is int[] srcArray)
        yield return! DoSomethingArray(srcArray); 
        // Does this method create an iterator wrapping the DoSomethingArray's iterator?

    ....
}

public IEnumerable<int> DoSomething(this IEnumerable<int> src)
{
    if (src is int[] srcArray)
        return DoSomethingArray(srcArray);
        // No new keyword, nor new syntax. And it is clear no extra iterator is created.

    ....
}

[HaloFour]

No new keyword, nor new syntax. And it is clear no extra iterator is created.

Another iterator has to be created because the execution of the iterator method itself is deferred. The method body doesn't execute until the consumer of the iterator calls MoveNext().

[karakasa]

It doesn't necessarily to be defered. For example:

        public static IEnumerable<int> DoSomething(IEnumerable<int> src)
        {
            if (src is int[] array)
            {
                // return DoSomethingOnArray(array);
            }

            yield return src.First();
        }

        private static IEnumerable<int> DoSomethingOnArray(int[] array)
        {
            return null;
        }

is complied into

[IteratorStateMachine(typeof(<DoSomething>d__1))]
public static IEnumerable<int> DoSomething(IEnumerable<int> src)
{
	<DoSomething>d__1 <DoSomething>d__ = new <DoSomething>d__1(-2);
	<DoSomething>d__.<>3__src = src;
	return <DoSomething>d__;
}

With the propsed mix, the compiled IL can just be:

[IteratorStateMachine(typeof(<DoSomething>d__1))]
public static IEnumerable<int> DoSomething(IEnumerable<int> src)
{
	if (src is int[] array)
		return DoSomethingOnArray(array);

	<DoSomething>d__1 <DoSomething>d__ = new <DoSomething>d__1(-2);
	<DoSomething>d__.<>3__src = src;
	return <DoSomething>d__;
}

Whether the consumer calls MoveNext() doesn't affect an iterator is saved as the iterator from DoSomethingOnArray is directly passed on.

[HaloFour]

That implies that such a feature could only ever be used if the compiler can prove that it's the only elements that could only ever be yielded down that path. But, even if it could, the compiler should definitely never do that implicitly as that radically changes the behavior of how iterator methods are expected to run. If there were to be an "eager" portion of an iterator that should have to be explicitly specified, and the compiler team has already considered a couple of proposals to that have have landed on local functions being a perfectly suitable way to accomplish that behavior:

    public static IEnumerable<int> DoSomething(IEnumerable<int> src) {
        if (src is int[] array) {
            return DoSomethingOnArray(array);
        }

        return impl();
        
        IEnumerable<int> impl() {
            yield return src.First();
        }
    }