Allow ConditionalAttribute for Task-returning method

[StephenCleary]

The asynchronous equivalent of a void-returning method is a Task-returning method. It seems natural to extend the valid uses of ConditionalAttribute to include Task-returning methods, with the semantics that for a "missing" method, its return value is a completed Task. This behavior is the same as modern auto-mocking libraries.

See also [http://stackoverflow.com/questions/43056131/mark-async-methods-that-just-return-a-task-with-the-conditional-attribute](this question on SO).

[svick]

Would it make sense to extend this to no-result tasklikes? (Like a potential non-generic ValueTask, which does not exist, because it would offer no benefit over Task.CompletedTask for the synchronous case.)

I don't know if such tasklikes are actually useful, but they do work.

[Mafii]

@svick I think that would definitely make sense.

Is the reason for limiting it to void that it avoids invalid code when the return value is used? Thing is that a task can also be assigned to a variable to await it later - so that might make the IL invalid, wouldn't it?

[jnm2]

@Mafii The C# compiler would just emit code to push Task.CompletedTask or similar onto the stack in place of emitting the call. Then if it's being awaited, the entire await Task.CompletedTask could be elided as a separate optimization, and if not, you still have a completed task object since you need one.

[svick]

Few more questions:

1. Should this apply also to partial methods?

2. What does code like F(ConditionalTaskMethod(i++), i++); do (assuming the relevant symbol is not defined)? Is it the equivalent to F(Task.CompletedTask, i++);?

   Previously, conditional methods could be called only directly, but with this proposal, presumably they could be called as a part of a larger expression. Would removing only some subexpressions from a larger expression be too confusing?