[cpp.predefined] Core language feature-test macros of future values

[frederick-vs-ja]

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [cpp.predefined]

Link to reflector thread (if any):

Issue description:

Some implementations can treat future features as extensions in old modes. Sometimes such a feature is denoted by a value of some feature-test macro larger than specified than [tab:cpp.predefined.ft]. I think it's better to allow larger values.

Suggested resolution:

Modify [cpp.predefined] as indicated:

(1.14) — __TIME__
[...]
?. Table 22 specifies names and least values of predefined feature-test macros. Each of these macros expands to an implementation-defined integer literal of the form yyyymmL that indicates a date and is larger than or equal to the specified least value.

Table 22 — Feature-test macros [tab:cpp.predefined.ft]

Macro name	Least vValue
[...]	[...]

[t3nsor]

This seems evolutionary IMHO

[eisenwave]

What you're describing is not a wording defect. There are clearly concerns for EWG to figure out here.

Also, I'm not convinced that we want to acknowledge "mixing" C++ compiler versions like using C++26 features in C++23.

[jensmaurer]

First of all, from a standards perspective, there is only one conformance level: either you conform to (say) C++23 or you don't. And all feature-test macros are then defined exactly as they are specified in the standard.

If your implementation is non-conforming in some respect (e.g. because it adds extensions from later standards), the C++ standard makes no statement about the degree of non-conformance.

Second, this particular change suggested here limits the ability of the C++ standardization effort to update values of feature-test macros (because an implementation might have already used a value updated in a later standard for something unrelated).

In any case, I agree this change is evolutionary and would need a paper targeted at EWG, with a bit of analysis.

[frederick-vs-ja]

Also, I'm not convinced that we want to acknowledge "mixing" C++ compiler versions like using C++26 features in C++23.

I think it's conforming to extend some C++26 features to C++23 as long as

• the features only make ill-formed cases accepted without changing existing behavior, and
• all of their uses are diagnosed with warnings.

And I only intended to talk about such cases. At least Clang is already doing so for some features and bumping corresponding FTMs in old modes...