Addition of explicit noexcept in common semantics by Robertkq · Pull Request #1044 · KhronosGroup/SYCL-Docs

Robertkq · 2026-08-22T14:11:35Z

fixes #1042
This PR adds the explicit noexcept to the following sections:

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

for the following functions:

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

The PR also contains some additional changes to make the tables prettier, it fixes alignment and just looks better overall but I can remove these changes / commit them for another PR if needed, otherwise, if these additional changes are welcomed, I'd also like to recommend either the removal or addition for both tables to contain the comments:

  // If any of the following five special member functions are declared,
  // then all five of them should be explicitly declared (see rule of
  // five).
  //
  // Otherwise, none of them should be explicitly declared
  // (see rule of zero).

I've done some analysis on the classes that use both by-value and by reference semantics and I found none that overwrite the behavior of the move constructor & assignment operator

This is my first PR to SYCL-Docs, please let me know if there are any inconsistencies between what is normally expected from contributors' PRs and mine, thanks!

CLAassistant · 2026-08-22T14:11:42Z

All committers have signed the CLA.

Robertkq · 2026-08-22T14:15:06Z

Kindly pinging for reviews, @TApplencourt @gmlueck @tahonermann

Thanks!

TApplencourt · 2026-08-27T14:39:20Z

Hi,

Sorry for the late reply. Amazing, thanks a lot!

We will try to discuss it soon during our weekly call. I will let you know ASAP,

Regards,
Thomas

gmlueck · 2026-08-31T13:02:31Z

+  friend bool operator==(const T &lhs, const T &rhs);

-  friend bool operator!=(const T& lhs, const T& rhs) { /* ... */ }
+  friend bool operator!=(const T &lhs, const T &rhs);


Our editorial style is to put the space after the &, not before. So the original spacing was correct. This line should be:

Suggested change

friend bool operator!=(const T &lhs, const T &rhs);

friend bool operator!=(const T& lhs, const T& rhs);

The synopsis in the text has the correct format. Could you change the spacing for the other declarations in this header and also "common-reference.h" to match this style?

I've changed this to the preferred editorial style. A small observation about this, I believe that the repository could benefit from a .clang-format file, just so that source code files that are used as reference can be modified with a higher confidence that coding style will remain consistent, don't think a CI job or anything should be needed to enforce it necessarely, but it would bring more convenience.

Anyways, hope it's good as is

@TApplencourt tried this once, but it changed a bunch of other formatting in ways we didn't like. Maybe it's possible to use clang-format in a way that doesn't do this, but we didn't discover that way.

In any case, thanks for the updates!

Yes, I tried but I failed so we removed it. But I guess now with AI, maybe easier to make it iterate over all the 1000 clang-format combination to find the one who doesn't change too much our current code :)

Thanks again!

LGTM. So our next discussion will be:

Should be back port this to SYCL 2020

What whould be we do will all the noexcept function who have precondition

Should be back port this to SYCL 2020

We looked at the DPC++ implementation, and we do not see any problem add these noexcept to SYCL 2020. Therefore, we'd be OK adopting this as a clarification / errata.

We looked at the DPC++ implementation, and we do not see any problem add these noexcept to SYCL 2020. Therefore, we'd be OK adopting this as a clarification / errata.

Does this require for this PR to be duplicated on the SYCL-2020 branch?

Also, out of curiosity, when is the expected release of SYCL-Next? Correct me if I am wrong, but SYCL-Next isn't just the next revision update for SYCL-2020, right? It's a separate set of specifications that up to date SYCL implementations will need to follow in the future?

Does this require for this PR to be duplicated on the SYCL-2020 branch?

No. If the WG approves this for SYCL 2020, I will make a separate PR to the SYCL 2020 branch.

It's a separate set of specifications that up to date SYCL implementations will need to follow in the future?

Exactly. Like a new version. In a new SYCL version, we are allowed to do some breaking change (that we will try to minimize ofc), and where some deprecated feature will be removed, etc

In new rev, we just "back-port" bug fixes.

TApplencourt · 2026-09-01T19:42:03Z

  ~T();

-  ...
+  // ...


Thanks! : ) I also prefer when our .h are valid c++

Robertkq · 2026-09-01T20:00:52Z

Is there anything else required from my side for this PR to be merged? I see that there is a workflow waiting for approval.

Really happy to contribute to SYCL-Docs, if I see any other possible improvements or inconsistencies, I will file an issue and PR! Thanks for the approvals

UPD: didn't read latest comments, I'll wait for you guys to have the meeting and discuss it, no rush from my side! Out of curiosity, is this a public meeting?

TApplencourt · 2026-09-01T21:03:39Z

Really happy to contribute to SYCL-Docs, if I see any other possible improvements or inconsistencies, I will file an issue and PR! Thanks for the approvals

Amazing! Thanks again, always good to have another pair of eyes for things we missed ! :)

Out of curiosity, is this a public meeting?

Sadly, no. It's restricted to the member of Khronos :( But your company are most than welcome to join : ) (https://www.khronos.org/members/).

We have also a SYCL Advisory Panel this one is free to join if you are interested.

Robertkq · 2026-09-01T21:42:18Z

We have also a SYCL Advisory Panel this one is free to join if you are interested.

I am contributing independently to SYCL, so I will try to join / request to join the SYCL Advisory Panel! Thanks for letting me know!

TApplencourt · 2026-09-17T15:51:57Z

SYCL Next: No objection so we can merge the PR
SYCL 2020 as a bug fix: Merge it into SYCL 2020 as a bug fixes.

CTS change required (we need to hold for change)
- https://github.com/KhronosGroup/SYCL-CTS need to be extended to verify no-except for the common-reference and common-by-value semantic

Robertkq · 2026-09-17T16:05:35Z

Happy to hear this :)
As far as I understand, I am not responsible to duplicate the PR on the SYCL2020 branch, although I don't mind if necessary.

About CTS change, I'd be more than happy to look into this, might take a bit in order to get familiar enough to add the checks properly but I hope to contribute more in the future so I wouldn't mind learning. Is it expected / OK if I take the responsability of adding the CTS checks?

Robertkq added 2 commits August 22, 2026 16:28

add noexcept to move ctor & asignment op

ec3bc9a

add noexcept to tables & make them prettier

55e4799

sycl-issue-bot Bot mentioned this pull request Aug 22, 2026

[Spec change] Addition of explicit noexcept in common semantics KhronosGroup/SYCL-CTS#1229

Open

Robertkq marked this pull request as ready for review August 22, 2026 14:13

gmlueck reviewed Aug 31, 2026

View reviewed changes

code style changes

f31c694

gmlueck approved these changes Sep 1, 2026

View reviewed changes

TApplencourt reviewed Sep 1, 2026

View reviewed changes

TApplencourt approved these changes Sep 1, 2026

View reviewed changes

dm-vodopyanov mentioned this pull request Sep 15, 2026

[SYCL][SYCL2020] Add missing noexcept to ctors of public SYCL RT classes intel/llvm#23184

Open

	friend bool operator!=(const T &lhs, const T &rhs);
	friend bool operator!=(const T& lhs, const T& rhs);

                 ~T();
-                ...
+                // ...

Uh oh!

Conversation

Robertkq commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CLAassistant commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Robertkq commented Aug 22, 2026

Uh oh!

TApplencourt commented Aug 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Robertkq commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TApplencourt commented Sep 1, 2026

Uh oh!

Robertkq commented Sep 1, 2026

Uh oh!

TApplencourt commented Sep 17, 2026

Uh oh!

Robertkq commented Sep 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Robertkq commented Aug 22, 2026 •

edited

Loading

CLAassistant commented Aug 22, 2026 •

edited

Loading

Robertkq commented Sep 1, 2026 •

edited

Loading