Skip to content

[FEA]: P2655R3 common_reference_t of reference_wrapper Should Be a Reference Type #10475

Description

@davebayer

This issue can be closed by implementing P2655R3

Activity

  1. HenrikGharagyozyan commented on Aug 1, 2026

    @HenrikGharagyozyan
    Contributor

    Hi! I'd like to take this one (I have two merged-track PRs in the repo, #10563/#10564). Plan: port libc++'s P2655R3 implementation — the __ref_wrap_common_reference_exists_with constraint plus the two mutually exclusive basic_common_reference partial specializations — into cuda/std/__functional/reference_wrapper.h, translated to CCCL's C++17-compatible machinery: the constraint as a _CCCL_CONCEPT, applied through basic_common_reference's fifth SFINAE parameter (same pattern as the existing tuple specialization) rather than native requires clauses, so it works across all supported dialects. The asymmetric exists_with(R,T) && !exists_with(T,R) condition prevents the wrapper-vs-wrapper self-ambiguity from the earlier paper revisions. Fully host-testable — I'll add static_assert coverage for the basic/mirrored cases, wrapper-vs-wrapper (ambiguity regression), const-correctness, and a negative case where no specialization may apply.

  2. moved this from Todo to In Progress in CCCLon Aug 2, 2026
  3. moved this from In Progress to In Review in CCCLon Aug 2, 2026
  4. davebayer commented on Aug 3, 2026

    @davebayer
    ContributorAuthor

    Hi @HenrikGharagyozyan, I assigned you to the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

C++23C++23 paper.libcu++For all items related to libcu++

Projects

  • Status
    In Review

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions