Clarify task types

[jskeet]

• Task and Task<T> are classified as task types despite not specifying builder types
• Interfaces are allowed to be task types
• Enums and methods are prohibited from being decorated with AsyncMethodBuilderAttribute
• Task types must not be generic in more than one type parameter (including in terms of containing types)

Discussion required for all of this, but if merged, would fix #854, #856, #858 and #859.

[jskeet]

cc @KalleOlaviNiemitalo for thoughts

@BillWagner I figure we can probably get this hammered into better shape between ourselves (I'm not entirely happy with the way the generic restriction is expressed) and then get broader review.

[KalleOlaviNiemitalo]

Task types must not be generic in more than one type parameter (including in terms of containing types)

That is not right. Type arguments of types that contain the task type should be ignored; Outer<char, int>.Inner<long> should be allowed as a task type if it has the correct attribute. But not as a task builder type.

[jskeet]

That is not right. Type arguments of types that contain the task type should be ignored; Outer<char, int>.Inner<long> should be allowed as a task type if it has the correct attribute. But not as a task builder type.

That would certainly be simpler to specify. Can I ask what your reasoning is here? I suspect it's more advanced than mine... and we should probably have a note to explain either way.

[KalleOlaviNiemitalo]

Or is the idea that, if the task type is nested in a generic type, then the task builder type would not be able to have a Task property with the correct type, unless it hardcodes the type arguments of the containing type? So that allowing such task types would not be useful in practice. Which would then make the Roslyn behaviour an extension.

[jskeet]

Or is the idea that, if the task type is nested in a generic type, then the task builder type would not be able to have a Task property with the correct type, unless it hardcodes the type arguments of the containing type? So that allowing such task types would not be useful in practice. Which would then make the Roslyn behaviour an extension.

That was my thinking, I think - but I feel like I'm still wading through cotton wool trying to think about this. I'm definitely not feeling like we should be bound by exactly what Roslyn allows, but I'm open to useful justifications.

[jskeet]

I've added another commit to basically copy the existing text from 15.15.2 (for task builders) and make it apply to task types.
This may be more restrictive than is strictly required (and Roslyn can allow a little more leeway), but I think it's a good starting point.

[jskeet]

I need to go back and reapply changes from #846 to this...

[jskeet]

Oops - no, I don't need to reapply changes from #846. It's all fine; @BillWagner does this look ready to merge?

[BillWagner]

This LGTM @jskeet

Let's