Allow 'yield break' in expression-bodied iterator method

[nillkitty]

I'm sure there's probably a good reason behind the scenes for this idiosyncrasy, but it feels like the following code should be valid, yet it does not compile:

public IEnumerable<IAccessEntry> GetAccessEntries() => yield break;

(returns CS0103: The name 'yield' does not exist in the current context.)

When implementing interfaces you sometimes need to return an empty/dummy IEnumerable, so I've run across this a few times over the last weeks mocking out some of my components. Impact is obviously low, but feels inconsistent/unintuitive.

I'm using C# 10 on .NET 6

[svick]

Why is this needed when you can return Enumerable.Empty<T>() instead? (Though you have to repeat T there.)

Or use a regular statement body, but write it on a single line?

public IEnumerable<IAccessEntry> GetAccessEntries() { yield break; }

[bernd5]

Good answer.
Btw: It is not allowed because yield break; is a statement not an expression.

[nillkitty]

@bernd5 your answer is a better answer IMO; you're right, it's not an expression, so this behavior isn't actually inconsistent.

@svick, thanks for making me aware of Enumerable.Empty<T>(), but I guess my biggest response to that is "how would I know that without having pre-memorized every method in the BCL?". I feel like dot-driven development is the cornerstone of C# and this is one gap -- I wouldn't otherwise know to look for members of the Enumerable type as a solution to this (or any) scenario because that type (Enumerable) is unrelated to any of the types i'm currently working with (IEnumerable<T>).

Would love to see (and i know this is outside the scope of this repo) a VS feature by which after typing an "=", intellisense can suggest method calls that result in the Type being assigned to based on what local variables (if any) are in scope and their types; e.g. typing Assembly a = might give you suggestions for Assembly.GetExecutingAssembly(), etc.

I had the same "oh what? this exists now?" feeling after learning about Array.Empty as well. and I read all the "what's new" docs and watch all the Mads talks, but these new members don't really get much fanfare.

[svick]

I guess my biggest response to that is "how would I know that without having pre-memorized every method in the BCL?".

Discoverability is a problem, but I don't think it justifies changing the language here.

To actually answer your question: use google. If you feel unsatisfied with your current solution, search the web for a better one. If I use your phrasing, the first result is an SO question with answers mentioning Enumerable.Empty, the second result is the documentation for Enumerable.Empty.

Would love to see (and i know this is outside the scope of this repo) a VS feature by which after typing an "=", intellisense can suggest method calls that result in the Type being assigned to based on what local variables (if any) are in scope and their types

ReSharper can do this with its Smart Completion:

(I also tried GitHub Copilot and, curiously, it doesn't suggest Enumerable.Empty for me. In other situations, it was able to "do the obvious thing" decently.)

these new members don't really get much fanfare

Array.Empty exists since 2015's .Net Framework 4.6 and 2016's .Net Core 1.0, so I wouldn't really call it "new". The (very long) article on .Net 6 from Monday does mention few nice additions to LINQ and other libraries.

[nillkitty]

Thanks; I no doubt would have found it easily if I knew I was looking for a static method on a static type named the same but without the "I", (as opposed to, say, a static method on IEnumerable<T> itself). I'm used to seeing the ITypename/Typename class relationship in DI and decoupling, but am not used to looking for the ITypename/Typename static class relationship for factories -- especially when its not obvious I need to instantiate something to return nothing. My bad!

[jnm2]

It's only become possible to declare static methods on interface types in 2019, and Enumerable.Empty() was added in 2008.