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
Following on from #2045 and #2046, we should consider whether it is worth adding some convenience APIs to make the use of Polly.Core's asynchronous common-case public members easier to consume in F# and VisualBasic where ValueTask/ValueTask<T> cannot be awaited.
For example, we could create a new Polly.Interop (or better named) extension package that exposes extension methods for types such as ResiliencePipeline that add Task-based overloads that wrap the usage of ValueTask from the caller, at the expense of additional allocations/performance overhead.
We may ultimately decide to do nothing and instead rely on documentation to help users of F# and VisualBasic consume Polly.Core APIs as they already are in version 8+.
This issue to is to collect feedback on whether people think this is worth doing, and an issue to point to decision making if we elect not to add such convenience APIs.
Appetite for this may be minimal given that it has taken 6 months for us to become aware of this usability issue.
The text was updated successfully, but these errors were encountered:
Following on from #2045 and #2046, we should consider whether it is worth adding some convenience APIs to make the use of Polly.Core's asynchronous common-case public members easier to consume in F# and VisualBasic where
ValueTask
/ValueTask<T>
cannot be awaited.For example, we could create a new
Polly.Interop
(or better named) extension package that exposes extension methods for types such asResiliencePipeline
that add Task-based overloads that wrap the usage ofValueTask
from the caller, at the expense of additional allocations/performance overhead.We may ultimately decide to do nothing and instead rely on documentation to help users of F# and VisualBasic consume Polly.Core APIs as they already are in version 8+.
This issue to is to collect feedback on whether people think this is worth doing, and an issue to point to decision making if we elect not to add such convenience APIs.
Appetite for this may be minimal given that it has taken 6 months for us to become aware of this usability issue.
The text was updated successfully, but these errors were encountered: