Replies: 2 comments
-
Hi, I'm also a big fan of But I think that in this library there's no need for that suffix since return GetAsync(id)
.Map(...)
.Bind(...)
.TapError(...)
.Compensate(...); And it's useful that you can more or less understand what is going on just by reading this chain, without digging in to I think the vast majority of used extensions in my projects are called on tasks, so I'll have to write a lot of return GetVersionAsync(id)
.MapAsync(version => version++); // map function is sync, but since it's called on a task (so it is so called `async left` overload), we have to await this task, so we have to add this suffix to `Map`s name So I think this change will break a nice domain language and just add suffuxes without any practical needs. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I wanted to add an Execute extension method for func ( practically a sugar syntax for Map ) but in doing so, i notice that the signature was clashing with the Execute ValueTask since it is not suffixed with Async.
So i was wondering why all theses Task/ValueTask async method are not suffixed with Async.
I can do the work to fix all of those everywhere by adding the Async suffix, but it would be a huge breaking changes. But considering that those changes were added less than 4 months ago. It shouldn't be that bad for those who are using those new extension methods.
so what do you think? can i do it?
Beta Was this translation helpful? Give feedback.
All reactions