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
ValueTask should only be used when the duration of a task in the majority of cases will be below 20ms. Not sure in which article i read this exactly (Stephen Cleary, i think), but in the majority of cases where networks are involved this is probably not the case. ValueTask returns force me to do async+await if i am interacting with a task, to get around ValueTask. But when you use async+await a state machine is returned which also isn't really ideal. Having control over ValueTask vs Task would be good.
The text was updated successfully, but these errors were encountered:
Hm, yeah, but in places where you interact with Send or similar methods it being a ValueTask would not be an issue. If it just changed for the RequestHandler interface it would be good enough. Because then you can just do
return HttpClient.GetStringAsync("somerequest"); if the returntype is string, instead of having to do async+await everywhere, just so it compiles (when you don't want to generate the statemachine but just directly return the task instead).
ValueTask should only be used when the duration of a task in the majority of cases will be below 20ms. Not sure in which article i read this exactly (Stephen Cleary, i think), but in the majority of cases where networks are involved this is probably not the case. ValueTask returns force me to do async+await if i am interacting with a task, to get around ValueTask. But when you use async+await a state machine is returned which also isn't really ideal. Having control over ValueTask vs Task would be good.
The text was updated successfully, but these errors were encountered: