Should more template arguments be propagated as members?

Most templated SYCL classes already expose a number of member aliases and `constexpr` variables for communicating meta information about the given instance of the classes. Examples of these are the member aliases `value_type` and `allocator_type` of `sycl::buffer` propagating the `T` and `AllocatorT` template parameters respectively and the `constexpr` member variable `address_space` of `sycl::multi_ptr` which propagates the value of the `Space` template parameter.

However, some of the template arguments are not propagated through such an interface. Examples of these are the `AccessMode` template parameter of `sycl::accessor` and `Dimensions` template parameter of `sycl::accessor`, `sycl::buffer`, `sycl::nd_range`, etc.

Having more of these as members could potentially simplify SFINAE and the use of `if constexpr`, for example if a user writes code specializing for a certain access mode of accessors. Should the specification extend the interface with more members like this?

Start with issue #270 and the open pull request #656, then review how the specification currently exposes template arguments for sycl::accessor, sycl::buffer, and sycl::nd_range. A decision on which additional members to specify, with consistent treatment of AccessMode and Dimensions, would define done.

Written by the indexing model from the issue text.