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

refactor: CPOs refactored to be more constrained #649

Merged
merged 7 commits into from
Nov 26, 2024
Merged

Conversation

mpusz
Copy link
Owner

@mpusz mpusz commented Nov 24, 2024

No description provided.

@mpusz
Copy link
Owner Author

mpusz commented Nov 24, 2024

@JohelEGP, is this what you meant?

@JohelEGP
Copy link
Collaborator

Yeah, that looks good.
I'm not too sure about constraining the parameter type.

@mpusz
Copy link
Owner Author

mpusz commented Nov 24, 2024

Do you think that the parameter should be unconstrained? I thought you asked me to contain it.

Should those CPOs also work with quantity that will model those interfaces? If so, then constraining the output with ScalarRepresentation is not a good idea.

@JohelEGP
Copy link
Collaborator

Do you think that the parameter should be unconstrained? I thought you asked me to contain it.

I think it's fine to leave it constrained.

Should those CPOs also work with quantity that will model those interfaces? If so, then constraining the output with ScalarRepresentation is not a good idea.

Good question, for LEWG, perhaps.
I don't know.

Comment on lines 69 to 71
// TODO clang-18 (and possibly other compilers) complain about the duplicated definition if `inline` is not used
template<>
inline constexpr bool disable_scalar<bool> = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that all variable templates are implicitly inline. It was a recent DR, so maybe it is not implemented in Clang for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true, but I don't think this is a variable template.
I can't find evidence that an explicit specialization is a template at all.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, you might be right

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, all global variables are inline: https://cplusplus.github.io/CWG/issues/2387.html. I believe that is a bug in clang.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although, I am not sure if I understand a note:

[Note: An instantiated variable template that has const-qualified type can have external linkage, even if not declared extern. —end note]

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to leave it explicitly inline.
The only case in the C++ Standard is at the end of https://eel.is/c++draft/fs.filesystem.syn.

JohelEGP
JohelEGP previously approved these changes Nov 26, 2024
@mpusz mpusz merged commit 81e83db into master Nov 26, 2024
147 of 151 checks passed
@mpusz mpusz deleted the cpo_refactor branch November 26, 2024 17:03
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.

2 participants