To async or not to async?
How would you define a library interface for a service that probably will be implemented with an in memory procedure - let's say returning a mapped value to a key you registered programmatically - and a user of your API might want to implement a decorator that needs a 'long running task' - for example you want to log a msg into your db or load additional mapping from a file?
Would you define the interface to return a Task<string> or just a string?
Used examples that first came into mind, but it could be anything really.
@Fandermill I'd go with Task. If it's performance critical, then you could consider both variations.
@mihamarkic But wouldn't that make all public interfaces defined as returning Task as you never know how users implement your interface? I guess it's really how the author of the API thinks it should be used of course.
@Fandermill Yep and yep. There is no magic solution. If you want flexibility, go with Task. If you want performance, go without Task. If you need both, implement both, though this might result in a lot of code duplication, so it might not be feasible - it depends. But again, are this methods be often called, like hammered? If not, I'd still go with Task (implicilty 'or ValueTask').