[Proposal] yield expression

[leandromoh]

Summary

Currently, the only way to create a lazy sequence with yield return is create a method (local or not). However sometimes things could be simpler. Instead of declare a method to use the lazy sequence it produces as a local variable or in a get expression of a property , we could create a "yield expression", in a similar way of switch expression feature.

Instead of write this boilerplate code

IEnumerable<string> names = _names();

IEnumerable<string> _names()
{
   yield return "bob";
   yield return "tom";
}

We could write something like

IEnumerable<string> names = yield
{
   return "bob";
   return "tom";
};

This feature would also allow create sequences of anonymous values with lazy evaluation in an optimum way. Since the current obvious approach we need to specify the return type in the method signature, there is no way to return an anonymous with the benefits of static typing.

Usage with anonymous:

var people = yield
{
   return new { Name = "bob", Age = 12 };
   return new { Name = "tom", Age = 24 };
};

Like iterator methods, "yield expression" would also allow declare variables, loops, conditions, capture outer variables, etc, but without generate any side-effect (like a iterator method that is a readonly member)

[YairHalberstadt]

I think local functions are a reasonable solution to the first point.
The second one about anonymous types is a great one!

I think if this were done, it also ought to be done for async blocks. Both scala and Rust support these.

[leandromoh]

@YairHalberstadt , local functions resolve the problem to the first point, but becomes a code smell, specially when you need to declare more than one sequence;

public IEnumerable<string> Names => _names();
public IEnumerable<int> Ids => _ids();

IEnumerable<string> _names()
{
    yield return "bob";
    yield return "tom";
}

IEnumerable<int> _ids()
{
    yield return 1;
    yield return 2;
}

Could be more clean like

public IEnumerable<string> Names => yield
{
    return "bob";
    return "tom";
}

public IEnumerable<int> Ids => yield
{
    return 1;
    return 2;
}

This feature propose a clean way of doing things, much like switch expression feature do.

[leandromoh]

@RUSshy what do you meant by "support high order functions directly"? C# supports high order functions with delegates, LINQ was done on top of this. Can you give us any example?

[leandromoh]

@RUSshy if I understood right, your example works the same way I proposed for yield expression.
yield { ... } returns a sequence, as well sequence { ... } in kotlin does.

Inside both {...}, we can do same things like in a method definition (declare variables, do loops, conditions, capture outer variables, etc).

[HaloFour]

Kotlin is a very different language, though. They have continuation primitives and suspendable functions which lend to constructing different kinds of coroutines, plus a syntax that lends itself to constructing DSLs. suspend is just a normal function and yield is just a normal method.

IMO if lambdas could be iterators in C# I think that would make it easier to solve this issue. A helper function like Enumerable.Create could be used with an iterator lambda. The language would have to solve for the generic inference as well, which could be tricky.

[leandromoh]

@HaloFour lambdas returning iterators would be nice too, but I suppose it is harder to be implemented, as you said, would be effort to improve 1) lambdas and 2) generic inference as well. yield expression are closer of syntax sugar for methods.

[CyrusNajmabadi]

@HaloFour lambdas returning iterators would be nice too, but I suppose it is harder to be implemented, as you said, would be effort to improve 1) lambdas and 2) generic inference as well. yield expression are closer of syntax sugar for methods.

I think we actually prototyped it one time, and it was fine. It's really more about it just not being compelling enough to add the complexity to the language. All the examples just never seem worth it, and the existing workarounds seem totally sufficient for what seems to be a 1% of a 1% case.

[HaloFour]

@leandromoh

lambdas returning iterators would be nice too, but I suppose it is harder to be implemented, as you said, would be effort to improve 1) lambdas and 2) generic inference as well. yield expression are closer of syntax sugar for methods.

I think the generic inference issue would have to be solved in both cases, at least if you wanted to assign this inline iterator to a var-typed local.

[leandromoh]

@HaloFour I supposed that for the inline iterator the var-typed would be simpler since today we already can define the people_eager variable like bellow:

var people_eager = new[]
{
    new { Name = "bob", Age = 12 },
    new { Name = "tom", Age = 24 },
};

what does not look syntactically so different of what is being proposed

var people_lazy = yield
{
   return new { Name = "bob", Age = 12 };
   return new { Name = "tom", Age = 24 };
};

however about delegate inference type, c# can not even do it for the simplest delegate type.
Following example gives us compiler error.

var simplestAction = () => { Console.WriteLine("hello world"); };

[Thaina]

I agree with @HaloFour that lambda iterator, allow using yield return in lambda, is more prefer in C#. Because that's how we have been writing iterator

And it could insert logic with yield return line by line unlike yield expression

var iter = Enumerable.Lambda(() => {
    yield return "bob";
    if(condition0)
        yield return "alice";
    yield return "tom";
});

[leandromoh]

@Thaina use yield return in lambda would be great too! But I think yield expression are more like switch expression. That is, you might just create a method with a switch case inside it, but switch expression remove the boilerplate code. yield expression has the same purpose. But of course, if any of both features about yield were added would be great!

One possible advantage, is that "yield expression" are closest of a readonly iterator method, that is, would also allow declare variables, loops, conditions, capture outer variables, etc, but without generate any side-effect, like a true expression.

Following code would be valid in my feature initial proposal.

public IEnumerable<string> Names => yield
{
    return "bob";
    if(condition0)
        return "alice";
    return "tom";
}

[Thaina]

@leandromoh In that aspect I have been create #249 about anonymous function expression in general. I think we should have expression to create a block of function that could return or yield return anywhere

For the shorthand property I still prefer

public IEnumerable<string> Names => {
    yield return "bob";
    if(condition0)
        yield return "alice";
    yield return "tom";
}

Even we have yield { expression } being a syntax I think we should still keep yield in front of return on every line. It might be a bit verbose but it guarantee not being ambiguous. Because naked return most likely make us all intuitively feel like it will break the imperative execution at that line

[leandromoh]

@Thaina I agree that return most likely make us all intuitively feel like it will break the imperative execution, but just create an "anonymous block" like in your last example make us intuitively feel like we could do anything that could be done in a normal method, losing the idea of expression, that is dont generate side-effect, what I think should be possible in a "anonymous block".

[CyrusNajmabadi]

Following code would be valid in my feature initial proposal.

This would prevent us from ever being able to have an expression that starts with { as this would not be ambiguous :-/

Given how niche yield is, it doesn't seem worth it to me.

[Thaina]

@CyrusNajmabadi As for me I think yield is not niche. It could be replace many constant new[] { x,y,z } in the code. I expect that if this syntax would implemented as a valuetype IEnumerable local function and so it might be more efficient than newing array every time. We could have complex logic to return the enumerable freely in the block

It felt niche because we have existing alternative. But if it has been implemented it might be used to replace the alternative code we have been using so far. In the same way as async IEnumerable

[leandromoh]

@Thaina I agree with your points. Return a new array every time in a get expression is expensive, and as you said this feature would allow us to have complex logic too.

[CyrusNajmabadi]

As for me I think yield is not niche. It could be replace many constant new[] { x,y,z } in the code.

That doesn't make it not niche.

It felt niche because we have existing alternative

Yes.

But if it has been implemented it might be used to replace the alternative code we have been using so far.

Yes, i get that. But that doesn't make it not-niche.

Return a new array every time in a get expression is expensive

No one is proposing htat. You can have iterators today. you justhave to name them with a method or local function. The question is if it's needed for an even less verbose way of doing things.

[leandromoh]

The question is if it's needed for an even less verbose way of doing things.

Yes. Yield expression has the same purposes of switch expression, if I understood it properly.

You always could create a method with a switch case inside it and do some side-effects, but switch expression remove the boilerplate code and make it an expression instead of a statement.

I am proposing to do the same thing with yield.

[CyrusNajmabadi]

I am proposing to do the same thing with yield.

Yes, i understand. :)

Let me try to state things differently: https://docs.microsoft.com/en-us/archive/blogs/ericgu/minus-100-points

It's not a question of "can we do this?" or "is this similar to something we've done?". It's a question of "is this valuable enough to do". I'm stating that this seems far to niche to warrant the work.

[IS4Code]

Expression blocks are another option to make this possible without new special syntax.

[ChayimFriedman2]

F# has that too.

[leandromoh]

Expression blocks are another option to make this possible without new special syntax.

@IllidanS4 the expression blocks proposal says "return, yield break, yield return are not allowed in the expression block statements." in its "Restrictions" section.

[IS4Code]

@leandromoh I presumed this restriction could be lifted, but that is based on the actual interpretation of the meaning of expression blocks.