| .. |
|
AssertEx.cs
|
ed708c40e3
Renaming a folder.
|
8 years ago |
|
AsyncQueryableExTests.Generated.cs
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
AsyncQueryableExTests.Generated.tt
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
NopObserver.cs
|
ed708c40e3
Renaming a folder.
|
8 years ago |
|
System.Interactive.Async.Providers.Tests.csproj
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
xunit.runner.json
|
ed708c40e3
Renaming a folder.
|
8 years ago |
Bart De Smet
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.