Change the base C++ version #680
Conversation
Change wording to allow the core C++ language to be any version C++17 or later. Move sections about normative references and non-normative wording to the introduction, so they are earlier in the document. My longer term goal is to remove "chapter/references.adoc" and add any references we require to the "Normative references" section. Some more work needs to be done for this to happen: * Decide if we need to list the C++ defect reports as normative references. Currently, the "references" appendix lists only DR2325. Is there a reason to list this one and not others? * Decide if OpenCL should be a normative reference. If so, which version(s)?
| All APIs in this specification are available regardless of the version of the | ||
| {cpp} core language unless the description specifically states otherwise. | ||
| If an API is documented with the phrase "Minimum C++ Version: __Version__", then | ||
| that API is available only if the version of the implementation's {cpp} core | ||
| language is at least _Version_. |
There was a problem hiding this comment.
I think the repetition of "C++ core language" here is confusing. The second sentence in this paragraph defines "C++ core language" to mean "C++17", so these sentences appear to be talking about different versions of C++17.
How about:
| All APIs in this specification are available regardless of the version of the | |
| {cpp} core language unless the description specifically states otherwise. | |
| If an API is documented with the phrase "Minimum C++ Version: __Version__", then | |
| that API is available only if the version of the implementation's {cpp} core | |
| language is at least _Version_. | |
| All APIs in this specification are available regardless of the {cpp} version | |
| unless the description specifically states otherwise. | |
| If an API is documented with the phrase "Minimum C++ Version: __Version__", then | |
| that API is available only if the SYCL implementation conforms to a {cpp} version of | |
| _Version_ or later. |
The first sentence in the paragraph already talks about SYCL implementations "conforming to" specific C++ versions, which is why I picked that wording.
There was a problem hiding this comment.
The term "C++ core language" is intended to identify whatever C++ version the implementation chooses. The first sentence says that an implementation must choose one of the versions listed in section <<sec:normativerefs>> (which are all the versions from C++17 and greater).
In practice, I expect that most SYCL implementations will choose the C++ version via a command line parameter like -std=.
There was a problem hiding this comment.
What happens when ISO C++26 is out but this is not yet mentioned in the SYCL spec as s normative norm? Is it up to the implementation whether a program using C++26 in host part will work? 🤔
There was a problem hiding this comment.
The term "C++ core language" is intended to identify whatever C++ version the implementation chooses. The first sentence says that an implementation must choose one of the versions listed in section
<<sec:normativerefs>>(which are all the versions from C++17 and greater).
Oh, I see. I misunderstood the sentence. I read "This version of C++" as referring to C++17, not as "the C++ standard to which a SYCL implementation conforms".
If we wanted to make this unambiguous we could say:
A SYCL implementation must conform to {cpp17} or to one of the more recent {cpp} versions listed in <sec:normativerefs>.
The version of {cpp} to which a SYCL implementation conforms is referred to as the {cpp} core language in this document.
or
A SYCL implementation must conform to a specific version of {cpp}, referred to as the {cpp} core language in this document.
The {cpp} core language must be {cpp17} or one of the more recent {cpp} versions listed in <sec:normativerefs>.
...but if I'm alone in thinking the original wording is confusing, you can ignore me!
There was a problem hiding this comment.
What happens when ISO C++26 is out but this is not yet mentioned in the SYCL spec as s normative norm? Is it up to the implementation whether a program using C++26 in host part will work? 🤔
I don't see this as a practical problem. There are already C++ compilers that support proposed C++26 features even though there is no ratified C++26 specification yet. Those compilers can exist -- they just aren't conformant to any spec yet. I think it could be the same for SYCL. An implementation can choose to support C++26 with SYCL if it wants. It just won't be strictly conformant to the SYCL spec.
What would be the alternative? I guess the SYCL spec could say that the core C++ version could be any future version of C++ even though we don't know what language features this would include. I think that would be more problematic because we wouldn't know how those unknown language features would work in device code.
This reminds me ... we should think through all the new language features in C++20 and C++23 and decide if they are legal in device code. For those that are not, we need to add them to section 5.5 "Language restrictions for device functions".
There was a problem hiding this comment.
If we wanted to make this unambiguous we could say:
I updated the wording according to your suggestion in d5d63ed.
Change wording to allow the core C++ language to be any version C++17 or later.
Move sections about normative references and non-normative wording to the introduction, so they are earlier in the document.
My longer term goal is to remove "chapter/references.adoc" and add any references we require to the "Normative references" section. Some more work needs to be done for this to happen:
Decide if we need to list the C++ defect reports as normative references. Currently, the "references" appendix lists only DR2325. Is there a reason to list this one and not others?
Decide if OpenCL should be a normative reference. If so, which version(s)?