Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bit.pow.two] Remove redundant Remarks specification #6820

Closed
wants to merge 1 commit into from

Conversation

Eisenwave
Copy link
Contributor

This paragraph is useless and should be removed.

[structure.specifications] p3.3 already states that precondition violations are undefined behavior. Evaluations with undefined behavior are not core constant expressions as per [expr.const] p5.8.

It could be argued that this paragraph is not only pointless but also harmful because it suggests that the precondition violations don't generally disqualify expressions from being constant expressions, only in this case, and this is surely not intended.

Even if we read this paragraph as

If a precondition is violated, the behavior is undefined, but it's not allowed for the undefined behavior to be a core constant expression.

... then what's the point of that? It just seems confusing.

@jensmaurer
Copy link
Member

jensmaurer commented Feb 23, 2024

[expr.const] p5.8 is restricted to core-language undefined behavior.

Here, the remarks in the library section establish a special case that this particular library undefined behavior is on par with core language undefined behavior, as far as constant evaluation goes.

@jensmaurer jensmaurer closed this Feb 23, 2024
@jwakely
Copy link
Member

jwakely commented Feb 23, 2024

Right, not all violations of library preconditions are guaranteed to produce an error during constant evaluation, e.g. using lower_bound on an unsorted range. This requirement is guaranteeing that the violation will be detected and diagnosed.

In an ideal world, maybe all violations would be diagnosed. But removing this paragraph does not get us closer to that ideal, instead it removes a useful guarantee and so makes the standard worse.

@Eisenwave
Copy link
Contributor Author

@jensmaurer I have brought shame upon myself. Thanks for clearing up my misconception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants