Implement asynchronous operations as async/await constructs

[fo-dicom]

Implement asynchronous operations as async/await constructs

[jussimattila]

I'm voting in favor of removing the Begin.../End.... It is a large breaking change, but perfectly acceptable for v2.0, I think.

[anders9ustafsson]

Thanks, @HisCodeness ! From a portability point of view, removing the Begin/End constructs is a good opportunity to get rid of the usages of (more-or-less) non-portable classes Thread and ThreadPool. On the other hand, as you point out, it is a large breaking change...

[jussimattila]

True, it is a large change, but I think that is actually a good reason to do it now at 2.0.0 instead of later. :)
Also:

• From a library user's point of view, having two options to do the same thing can be confusing.
• In a couple of years, there will be devs who have had little exposure to Begin/End and don't really know what it is when they see it, but are comfortable with the language level async/await construct.
• Having to maintain two code paths doing the same thing is not desirable in the long run.
• When adding new features, you don't want to write two implementations just to allow clients be consistent.
• Async/await is much cleaner way of doing async, so forcing clients to adopt that is fine IMHO.
• And as you mention, portability is simplified.

Disclosure: Affecting my stance on this is that I don't have a legacy project I couldn't port to fo-dicom 2.0.0, including moving to async/await, when the time comes.

[anders9ustafsson]

Thank you, @HisCodeness , you have given me the right arguments to proceed :-)

[IanYates]

I agree with @HisCodeness, it makes sense to avoid two ways of doing things.

If you want code-level backwards compatibility (so you couldn't just drop in a newer dicom.dll - you'd need a recompile instead) we could add in extension methods to still use the Begin/End and IAsyncResult pattern using the ideas from half way down http://blog.stephencleary.com/2012/07/async-interop-with-iasyncresult.html or the entire post at http://bartwullems.blogspot.com.au/2013/07/going-from-tasks-back-to.html

That would avoid the double-implementation whilst providing a nice migration path for those relying on the old async pattern.