KhronosGroup / KhronosGroup/SYCL-Docs

Explicit addition of `noexcept` for common functions

Open
#1,042 5 comments 1 reaction 0 assignees View on GitHub
Agenda clarification
Dominant language
JavaScript
Stars
158
Forks
80
Avg merge
7d 6h
Merged PRs (30d)
5

Description

### Specification Version

SYCL 2020 (Revision 12)

### Section Number(s)

3.5.2. Common reference semantics
3.5.3. Common by-value semantics

### Issue Description

I would like to make a request to specifications for adding the `noexcept` keyword for the following:

1. All `~T()`
* Why?

* I believe it's good standard practice to mark destructors as noexcept as it addresses issues with stack unwinding for exceptions and solves the issue where you have multiple exceptions at once. If I recall correctly, a non-explicitly noexcept default constructor gets the noexcept trait either way from all modern compilers, but I think it's a good addition to add it explicitly nevertheless

2. For functions of classes that adhere to `Common reference semantics` & `Common by-value semantics`
* Why?

* For the `move constructor` & `move assignment operator`, I believe it would be beneficial to add the `noexcept` keyword, I believe that classes that adhere to `common reference semantics` would benefit more from this. The `STL` uses the following [move_if_noexcept](https://en.cppreference.com/cpp/utility/move_if_noexcept) function when deducing if a move can be performed instead of a copy where preferable, `noexcept` is needed to keep the strong exception guarantee of containers

I hope `clarification` issue type is the appropriate type for this. If it is desired for this addition to be accepted in the specifications and it's possible for me to contribute, I would very much like to do so!

Any comments are welcomed!
Thanks!

### Code Example (Optional)

```cpp
~T() noexcept = default;

T(T&&) noexcept;
T& operator=(T&&) noexcept;
```

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading SYCL 2020 sections 3.5.2, Common reference semantics, and 3.5.3, Common by-value semantics, then compare their requirements with the proposed destructor, move-constructor, and move-assignment declarations. Done means the specification has a resolved, reviewable decision on where explicit noexcept requirements belong, with the relevant wording and examples updated if accepted.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.