[Spec clarification] async_handler — is the std::function alias normative or illustrative?

[koparasy]

Specification Version

SYCL 2020 (Revision 11)

Section Number(s)

§4.13.1.1 "Asynchronous error handler"
4.13.2

Issue Description

§4.13.1.1 "Asynchronous error handler" programming_interface.adoc:17615–17616, states the async_handler "may be a named function object type, a lambda expression or a std::function", non-exhaustive language:

"""
The async_handler may be a named function object type, a lambda expression or a std::function. The exception_list object passed to the async_handler is constructed by the SYCL runtime.
"""

The corresponding C++ example in exception.h:6, defines:

using async_handler = std::function<void(sycl::exception_list)>;

Two readings of how these relate:

1. Normative alias. "May be" lists permitted call-site forms; the underlying storage must be std::function. Implementations have no freedom.
2. Illustrative alias. Narrative permits any matching callable; the alias is one valid concrete choice.
   The spec has precedent for explicitly marking illustrative types: __unspecified__, __unspecified_iterator__, enum class _ : /* unspecified */.

The async_handler alias has no such marker, suggesting reading 1. Reading 1 fully constrains storage type; reading 2 leaves room for implementation choice, matching the narrative's permissive "may be" wording.

Questions:

1. Is the alias normative (reading 1) or illustrative (reading 2)?
2. If reading 2, would the WG accept a marker (e.g. __unspecified_callable__, /* exposition only */, or a "named requirements" table) in a future revision?
   Could the WG clarify intent? If reading 2 is intended, would marking the alias as unspecified_callable (or /* exposition only */) be acceptable?

Code Example (Optional)

No response

[TApplencourt]

@nliber is on vacation, so he cannot said no, so I will throw him under the bus. I will ask him about this when it's back :)

Thanks for the report!

[TApplencourt]

WG: Agree to change

using async_handler = std::function<void(sycl::exception_list)>;
to be more general / unspecified callable

PR welcome.

[koparasy]

@nliber Any progress on this, would you like me to pick this up?

[koparasy]

@TApplencourt can we put this back on the agenda? IIRC we had decided to make the std::function on the async_handler as a __unspecified_callable__ .

[TApplencourt]

No problem. Will add it to the agenda. Thanks!

[TApplencourt]

@nliber say "yes I will do with pleasure for next week!" :D