P3385R7 - Attributes reflection

Author: Aurelien Cassagnes | Date: 2026-01-13 | Audience: SG7, EWG, LEWG

Paper link: wg21.link/p3385r7

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

Reminder: paper authors sometimes read these threads. Critique the design, not the person.

Seven revisions. Seven. And along the way they removed [[assume]] support entirely. The committee giveth and the committee taketh away.

I've read the whole thing and I think the interesting tension in this paper isn't the API surface - it's the categorization system it creates. The paper establishes a three-tier hierarchy of attributes:

1. Standard attributes (fully supported, reflection guaranteed)
2. Vendor attributes (conditionally supported, up to the implementation)
3. Unknown attributes (unsupported, ill-formed to reflect)

And then it codifies this with two rules:

Creating reflection of unsupported attribute is ill-formed (diagnostic required)

attributes_of does not return unsupported attributes

This means the reflection system now has a visible seam between "attributes the implementation knows about" and "attributes it doesn't." Before this paper, that seam was invisible to user code - the compiler silently ignored unknown attributes. After this paper, your metaprogram can observe the difference, because attributes_of will return different results on different compilers depending on which vendor attributes they've opted into supporting.

That's a defensible design choice - the alternative (reflecting unknown attributes as opaque tokens) would be much harder to specify. But it means that generic code using attribute reflection is inherently non-portable across implementations. The paper acknowledges this in section 3.2, but I think it deserves more attention than a paragraph. This is the kind of thing that bites library authors three years after the feature ships.

The godbolt link in the paper is the first time I've seen ^^[[ in the wild and honestly it looks like line noise that gained sentience.

The change to data_member_options is going to bite anyone already using P2996's define_aggregate. The paper deprecates no_unique_address as a boolean field and replaces it with a general-purpose vector<info> attributes member. That's a cleaner design, sure, but every existing call site that has .no_unique_address = true now gets a deprecation warning.

What's the migration story here? The paper shows the replacement:

.attributes = {^^[[no_unique_address]]}

But that's a more verbose spelling for the same thing, and it means you need the attribute reflection machinery just to set a layout property. I get why it's better architecturally - you can now attach any attribute, not just the one they hard-coded - but the deprecation timing feels aggressive for a feature that just shipped.

The [[assume]] exclusion is the right call and the paper is honest about why. The core problem is expression identity:

Should ^^[[assume(i + 1)]] compare equal to ^^[[assume(1 + i)]]?

Canonicalizing arbitrary expressions is an unsolved problem in the general case. You either do token comparison (which gives surprising results - i + 1 != 1 + i) or you try to normalize (which is undecidable for complex expressions). The paper's experimental implementation uses token comparison, which works but would be a terrible thing to standardize.

The practical impact is near zero anyway. [[assume]] can only appertain to the null statement, so attributes_of would never return one. The only way to get an assume reflection is to construct one explicitly, and there's no use case for that.

Edit: I should clarify - the Bloomberg Clang fork does have experimental support for expression-argument attributes using token comparison. It works fine in practice. The issue is purely about what semantics to bless in the standard.

I'm more interested in when C++ will get user-defined attributes. The paper explicitly says unknown attributes are "unsupported" and reflecting on them is ill-formed. So we get to inspect the attributes the committee blesses, but anything from my own codebase is invisible to reflection. Every other language with a reflection system figured out that user annotations are the killer feature.

The motivating example is actually compelling. Filtering out deprecated members at compile time:

for (auto member : nonstatic_data_members_of(^^T, ctx)) {
  if (!has_attribute(member, ^^[[deprecated]])) {
    migratedMembers.push_back(
      data_member_spec(type_of(member),
        {.name = identifier_of(member)}));
  }
}

Clean, readable, does what it says. But notice what's missing: this is read-only. You can inspect attributes and filter on them, but you can't create new attributes or programmatically attach attributes to entities that don't have them. The define_aggregate extensions let you carry attributes forward, but there's no add_attribute or equivalent.

For the "migrate away from deprecated" use case that's fine. For the "generate Python bindings with @deprecated decorators" use case mentioned in the intro, you still need an external code generator to produce the Python side. The reflection helps you identify what to tag, but you're on your own for the tagging.

P2996 barely got into C++26 and we're already stacking extensions on top. Can we at least wait for implementations to stabilize before bolting on more features? Or is that too much to ask.

The committee poll history on this paper is worth reading carefully. SG7 gave unanimous encouragement on R1, but then the consensus fractured:

- Dec 2024: no consensus on reflecting full expression arguments (expected)
- Dec 2024: no consensus on forwarding target - C++26 or C++29 (interesting)
- Feb 2025: consensus to forward to EWG/LEWG as-is
- Sofia: EWG told them to drop appertain and focus on querying

But here's the one that matters: "EWG encourages more work on reflecting attributes in the direction of the paper" got a 1/14/12/3/2 split (SF/F/N/A/SA). That's fourteen in favor, twelve neutral, and five against. Not consensus. Fourteen neutral-to-negative votes on a directional question is the committee saying "we're not sure this is the right shape."

R7 responds by dropping appertain and [[assume]] - which is what EWG asked for. The question is whether the slimmed-down version satisfies the skeptics or whether they wanted a fundamentally different approach.

Ah yes, my favorite C++ activity: reading a 20-page paper to find out that I still can't do what Java developers do with @Deprecated and a single line of reflection code. We're getting there though. Only two more standards cycles and a dozen more papers.

One use case the paper undersells: automatic Python/Lua binding generation. If you're already using P2996 to enumerate members and generate bindings at compile time, attribute reflection lets you skip deprecated members, respect [[nodiscard]] in the binding wrapper, and carry [[maybe_unused]] through to suppress warnings in generated code. That's a real quality-of-life improvement over the current approach where binding generators either ignore attributes entirely or require a separate annotation mechanism.

The attributes_of API is the right primitive for this. My concern is with the return type: vector<info> with unspecified ordering. For code generation you need deterministic output.

For embedded, vendor attributes are the ones that matter: [[gnu::section("...")]], [[gnu::packed]], [[clang::no_sanitize("...")]]. The standard attributes are nice for library ergonomics, but the vendor ones control memory layout, linking, and codegen in ways that affect whether your firmware fits in flash.

The paper makes vendor attributes "conditionally supported" which is the right design. But the practical question is whether GCC and Clang will actually opt in. If the major compilers don't support reflecting on their own vendor attributes, this feature is limited to checking [[nodiscard]] and [[deprecated]] on types you already control. Useful, but not transformative.

I for one welcome our new consteval overlords.

Genuine question: does anyone actually use [[nodiscard]] with a message string? I've been writing C++ for 8 years and I've never seen [[nodiscard("reason")]] in production code. The entire argument-clause comparison machinery feels over-engineered for an argument type that nobody uses.