C# V7: Generalized async return types

[RexJaeschke]

Questions re 14.15 Async Functions|14.15.1 General:

A. Re System.Runtime.CompilerServices.AsyncMethodBuilder, in the absence of a CLI spec update, presumably, we’ll need to spec this attribute type. Or at least update §C.3, “Standard Library Types not defined in ISO/IEC 23271” to include this new Attribute type.

B. §11.8.8.2, “Awaitable expressions,” allows for the possibility of the awaiter implementing ICriticalNotifyCompletion. What, if anything, should we say about awaiter/builder types being required/permitted to implement ICriticalNotifyCompletion?

Bill W.: Maybe. We (the ECMA committee) stuck with just INotifyCompletion. As such, this may be an implementation detail. Let’s discuss in committee.

C. Where are the semantics of the TaskBuilderType methods defined? Is there some sort of IBuilderMembers interface that an awaiter should implement, or does the awaiter simply have to declare each of those members?

Bill W.: My first thought is to follow the example of LINQ query expressions: A type must follow a “shape”, but what those methods actually do isn’t spelled out in detail in the spec.

D. Is there some spec for the V6 state-machine code generation for Task and Task<T> that I can adapt for all task types?

Bill W. I don’t think so, but from my comment above, we may not need to add this.

E: In which section should the spec for state-machine code generation go? In the async-return spec it’s listed under “Execution.”

Bill W. Do you think we need something like this: §12.17.3 Query expression translation? That’s my first thought.

General question:

F. How/where do I merge in the text from the async-return spec section “Overload Resolution?” Maybe in 11.6.4.5, “Exactly matching expression.”

@gafter On yesterday's TG2 call you said you'd like to run this PR by an expert. I've spec'd all that I can for this feature, and listed the open issues above.

[gafter]

I've asked @ljw1004 to look at this.

[BillWagner]

The PR for local functions will be merged before this one.

This PR should be updated per #104 (comment) to address other allowed return types in async local functions.

[BillWagner]

See #345 for more questions on this feature

(Rex closed 345 on 2023-02-19.)

[BillWagner]

link to feature speclet

[BillWagner]

Re System.Runtime.CompilerServices.AsyncMethodBuilder, in the absence of a CLI spec update, presumably, we’ll need to spec this attribute type. Or at least update §C.3, “Standard Library Types not defined in ISO/IEC 23271” to include this new Attribute type.

I added the declarations in §C.3 for System.Runtime.CompilerServices.AsyncMethodBuilder.

§11.8.8.2, “Awaitable expressions,” allows for the possibility of the awaiter implementing ICriticalNotifyCompletion. What, if anything, should we say about awaiter/builder types being required/permitted to implement ICriticalNotifyCompletion?

C. Where are the semantics of the TaskBuilderType methods defined? Is there some sort of IBuilderMembers interface that an awaiter should implement, or does the awaiter simply have to declare each of those members?

D. Is there some spec for the V6 state-machine code generation for Task and Task that I can adapt for all task types?
E: In which section should the spec for state-machine code generation go? In the async-return spec it’s listed under “Execution.”

I addressed all of these by adding the text for the semantics of the TaskBuilderType members. There isn't an interface, but the compiler expects certain semantics. That text is in a new clause under §14.15. It specifies what calls the compiler generates to create an instance of the builder type and what methods will be called for that builder type.

F. How/where do I merge in the text from the async-return spec section “Overload Resolution?” Maybe in 11.6.4.5, “Exactly matching expression.”

I added the first rule to "Exactly matching expression". The second and third I added to "Better conversion target".

[BillWagner]

No further comments for any invited reviewers.

@jskeet Can we look at this one for the upcoming meeting as well?

[jskeet]

Yup, absolutely. Please add the label - it's fiddly to do on my phone...

[jskeet]

A few comments - I'm okay to go with a somewhat vague wording for «TaskType» in the hope that we tighten it up before final submission.

(There are a few other changes that should be easier to make or reject.)

[BillWagner]

@jskeet Async return types is rebased and ready for the upcoming meeting.

[jskeet]

Approved on 2023-05-17 meeting.