KhronosGroup / KhronosGroup/SYCL-Docs
Should accessor::operator[](id<Dim>) only be available for Dim > 1?
- Dominant language
- JavaScript
- Stars
- 158
- Forks
- 80
- Avg merge
- 7d 6h
- Merged PRs (30d)
- 5
Description
Currently, we have `accessor::operator[](id)` available for device accessors if Dim > 0:
https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_interface_for_buffer_command_accessors
I believe this can cause ambiguities if `accessor::operator[]` is used with `item<1>` as argument instead of `id<1>`:
* `item<1>` can be implicitly converted to `id<1>`, for which an `accessor::operator[]` overload exists
* `item<1>` can be implicitly converted to `size_t`, for which an `accessor::operator[]` overload exists as well.
Do we want to support passing `item` to `accessor::operator[]`? If so, I think one solution could be to make the `accessor::operator[](id)` only available for Dim > 1. This is how I have solved this at the moment.
Passing `id<1>` still works, because then `id<1>` would be implicitly converted to `size_t`, and then `accessor::operator[](size_t)` can be used.
I'm curious how other implementers have solved this, because going strictly by the synopsis as defined in the spec will not work I think.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the SYCL 2020 interface for buffer command accessors linked in the issue and compare its accessor::operator[] overloads for id, item<1>, and size_t. Resolve whether item<1> should be supported and whether the id overload is restricted for Dim > 1; done means the specification records an unambiguous, agreed behavior.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100