Task.Run as an anti-pattern?

Question

I am using the SQLite.NET PCL library for my WinRT projects with the SQliteAsyncConnection class, which offers async versions of the classic SQLiteConnection methods. However, on the project's Github page the following is stated:

Please be aware that the Task.Run pattern used in SQLiteAsyncConnection can be considered an anti-pattern (libraries should not provide async methods unless they are truly async). This class is maintained for backwards compatibility and for use-cases where async-isolation is handy

Why is using Task.Run in this case considered an anti-pattern? This allows the developer to achieve exactly the goal he needs - to run the database access code on a separate thread while the app stays responsive to user input. Would it be better to manually write Task.Run snippet each time and not use the async version of the class altogether?

What are the potential issues and setbacks of this pattern?

Answer 1

Yes. It would be better if the consumer for the library will explicitly state that he wants to offload that work to a different thread (if that occurs more than once they can have a helper method just as the library has).

Otherwise they might believe that this method is inherently asynchronous. Which is not the case and you can't know that unless you can look at the source code.

A longer explanation could be found in Should I expose asynchronous wrappers for synchronous methods?. Specifically:

I believe the only asynchronous methods that should be exposed are those that have scalability benefits over their synchronous counterparts. Asynchronous methods should not be exposed purely for the purpose of offloading: such benefits can easily be achieved by the consumer of synchronous methods using functionality specifically geared towards working with synchronous methods asynchronously, e.g. Task.Run.