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:
- Normative alias. "May be" lists permitted call-site forms; the underlying storage must be std::function. Implementations have no freedom.
- 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:
- Is the alias normative (reading 1) or illustrative (reading 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
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:
Two readings of how these relate:
The spec has precedent for explicitly marking illustrative types:
__unspecified__,__unspecified_iterator__,enum class _ : /* unspecified */.The
async_handleralias 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:
__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