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

Outline migration path from tag_invoke for codebases that have a homebrew implementation / use libunifex #20

Open
atomgalaxy opened this issue Feb 17, 2022 · 7 comments

Comments

@atomgalaxy
Copy link
Owner

image

@lewissbaker
Copy link
Collaborator

lewissbaker commented Feb 18, 2022

Not that having a generic override like this will require having some way to find that overload by adl. Currently we don't consider the cpo type itself as an associated entity but maybe we should.

This may also be useful for types to customise foo for their type T even if they don't have any args in their namespace. Eg parse<T>(std::string_view)

@cor3ntin
Copy link
Collaborator

Currently we don't consider the cpo type itself as an associated entity but maybe we should.

That seems extremely purpose defeating

@lewissbaker
Copy link
Collaborator

Because of the extra namespace to search?

@cor3ntin
Copy link
Collaborator

Oh, i think i misunderstood. You want the generic override to be found in the cpo's NS rather than the cpo itself being found by adl, which scared me.
Then yes, I think it would make sense, maybe. definitively worth considering.

@atomgalaxy
Copy link
Owner Author

atomgalaxy commented Feb 18, 2022 via email

@h-vetinari
Copy link

Any update on the R2 effort after R1 was seen by EWG?

@atomgalaxy
Copy link
Owner Author

atomgalaxy commented Mar 5, 2023 via email

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

No branches or pull requests

4 participants