Add sycl_khr_free_function_commands extension #644
Conversation
This extension provides an alternative mechanism for submitting commands to a device via free-functions that require developers to opt-in to the creation of event objects. It also proposes alternative names for several commands (e.g., launch) and simplifies some concepts (e.g., by removing the need for the nd_range class).
| group<Dimensions> get_work_group() const noexcept; | ||
|
|
||
| sub_group<Dimensions> get_sub_group() const noexcept; |
There was a problem hiding this comment.
Just out of curiosity, did we end up reaching an agreement on when new APIs should have the get_ prefix?
There was a problem hiding this comment.
I don't think so. And -- annoyingly -- ISO C++ doesn't seem to be consistent, so we can't really rely on precedent.
The convention I've tried to follow when sketching out these KHRs is to use get_ as a syntactic hint that an implementation is either 1) doing more than just returning a member of a class; and/or 2) that the thing being returned conceptually exists outside of the class.
So invocation::id() and invocation::range() don't have the get_ prefix because instantiating an id and a range within each invocation is likely to be a common implementation choice, and because these properties conceptually "belong to" [/handwave] each invocation.
invocation::get_group() and invocation::get_sub_group() have the get_ prefix because implementations might have to look-up which group an invocation belongs to and construct a group/sub_group class, and because the groups themselves conceptually exist outside of the invocation.
Although we don't have a clear precedent to follow, this at least seemed closely aligned to how several ISO C++ classes behave. For example, in std::vector, the pointer returned by data() "belongs to" the class, whereas the allocator returned by get_allocator() conceptually exists outside of the vector.
There was a problem hiding this comment.
The convention I've tried to follow when sketching out these KHRs is to use get_ as a syntactic hint that an implementation is either 1) doing more than just returning a member of a class; and/or 2) that the thing being returned conceptually exists outside of the class.
I suspected something along those lines; I think it's a good way of handling it!
There was a problem hiding this comment.
Meta comment but I will be nice if we can keep those "design principle" somewhere, so we don't forget them we will add new APIs
This extension provides an alternative mechanism for submitting commands to a device via free-functions that require developers to opt-in to the creation of event objects.
It also proposes alternative names for several commands (e.g.,
launch) and simplifies some concepts (e.g., by removing the need for thend_rangeclass).