You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, we thought this would be handled by the general feature of allowing pattern-based foreach to use extension methods. But that was split into a separate feature (hopefully still candidate for 8.0).
Even if we don't do it for regular foreach, LDM wants to do this for await foreach.
And when we do it, the order should be: (1) instance method, (2) interface, (3) extension method.
That order matches the behavior we want for foreach and we also think it is sensible in general.
From LDM 1/9.
[Fact]publicvoidTestGetAsyncEnumeratorPatternViaExtensions(){stringsource=@"public class C{ async System.Threading.Tasks.Task M() { await foreach (var i in new C()) { } } public sealed class Enumerator { }}public static class Extensions{ public static C.Enumerator GetAsyncEnumerator(this C c) { throw null; }}";varcomp= CreateCompilationWithMscorlib46(source);
comp.VerifyDiagnostics(// (6,33): error CS8411: Async foreach statement cannot operate on variables of type 'C' because 'C' does not contain a public definition for 'GetAsyncEnumerator'// await foreach (var i in new C())
Diagnostic(ErrorCode.ERR_AwaitForEachMissingMember,"new C()").WithArguments("C","GetAsyncEnumerator").WithLocation(6,33));}
The text was updated successfully, but these errors were encountered:
If this was implemented it would allow EF Core to define an extension method in our main namespace that would enable our IQuerayble<T> based queries to be directly consumed with await foreach:
varorders=fromoin context.Orders.Include(o => o.Lines)where o.Status == OrderStatus.Pending
selecto;awaitforeach(var o in orders){
Process(o);}
Currently we define AsAsyncEnumerable<T>() so our customers can do it like this:
varorders=fromoin context.Orders.Include(o => o.Lines)where o.Status == OrderStatus.Pending
selecto;awaitforeach(var o in orders.AsAsyncEnumerable()){
Process(o);}
Previously, we thought this would be handled by the general feature of allowing pattern-based
foreach
to use extension methods. But that was split into a separate feature (hopefully still candidate for 8.0).Even if we don't do it for regular
foreach
, LDM wants to do this forawait foreach
.And when we do it, the order should be: (1) instance method, (2) interface, (3) extension method.
That order matches the behavior we want for
foreach
and we also think it is sensible in general.From LDM 1/9.
The text was updated successfully, but these errors were encountered: