Issue 1027: Member declaration attributes and composite types

Authors: Joseph Myers
Date: 2026-02-27
Submitted against: C23
Status: Open
Cross-references: 1013

The rules for redeclaration of structure, union and enumerated types, and for compatibility and composite type, do not address how attributes on members (not on their types) are handled. This is different from the questions in issue 1013 around "same type" when the attributes are part of the type of a member.

Question 1

What are the effects of variations in attributes for redeclarations of the same type?

struct s {
  [[deprecated]] int a;
  int b;
} x;
struct s {
  int a;
  [[deprecated]] int b;
} y;

The types of the members are clearly the same (the attribute appertains to the member, not its type), so it appears this is valid (and both definitions of struct s, being in the same scope and using the same tag, also thus declare the same type). Does the rule about [[maybe_unused]] and [[deprecated]] that "An entity is considered marked with the attribute after the first declaration that marks it." apply to member declarations as it does to other cases of multiple declarations of the same entity? Would subsequent references to x.a, x.b, y.a and y.b thus all be considered references to a deprecated entity, since x and y have the same type, where both members are deprecated? (An example of this was raised in GCC bug 119526.)

Question 2

How do such variations affect composite types?

struct s {
  [[deprecated]] int a;
  int b;
} x;

void
f(int i)
{
  struct s {
    int a;
    [[deprecated]] int b;
  } y = { i, i };
  (i ? &x : &y)->b = 1;
}

In the composite of two compatible types in (i ? &x : &y), which members are considered deprecated? The rule for composites of structure and union types does not consider any information about the members (such as attributes) that might be different, but not affecting compatibility and not part of the types of those members.