Consider making methods of range and index space types noexcept

[AlexeySachkov]

This report originated from a discussion about a change to Intel's SYCL implementation to handle exceptions which can potentially fire from within noexcept functions (as discovered by a static code analyzer) here: intel/llvm#15173 (comment)

Section 4.9.1. Ranges and index space identifiers defines several classes: range, nd_range, id, item, h_item, nd_item and group with many methods and I think that all those methods should be marked as noexcept.

item, nd_item, h_item and group are not even user-constructible, meaning that they can only be used within kernels where exception-handling cannot be used. There is some unclarity about what that means discussed in #543, but my understanding is that the spirit of the SYCL specification is that you can't throw exceptions from device code. Therefore, I don't think that users should expect exceptions being thrown from any methods of those functions.

range, nd_range and id are user-constructible and they are used on host as well, so they are a bit trickier. I suppose that it is not a good idea to have different noexcept specification for host and device compilation (won't it be an ODR violation or something like that?), but perhaps all their methods should anyways also be marked as noexcept consistently.

A few more notes about those user-constructible classes:

• They have get_* APIs and subscript operators which accept an index and the spec is not clear what should the behavior be if the index is invalid, see Expected behaviour of nd_item get_global_id(x) where x>NDims #551. An exception is one of a possible solutions, but we can't use them on device, or can we?
• Some of those have .size() method which can potentially results in integer overflow (if range is too huge, for example). But considering that their components are size_t and therefore unsigned, I think that we can ignore that overflow, because it is well-defined for unsigned types.

I think that addition of noexcept sets better requirements for implementations and improves consistency of the specification with respect to things which are illegal in device code.