If an implementation chooses to ignore the attribute,
does it mean the implication doesn't hold?

To elaborate, I think this would primarily be a transitional tool (e.g., for old code where you can't or don't want to add/change to the annotation).

I suspect this would eventually result in attributes being "discouraged" for most use cases in favor of annotations that have more well defined semantics. I could picture a world where "annotations" are never ignored but sometimes have no effect. Given reflection and the class based design, I suspect we could do a lot better than the (several times discussed) points of "what does it mean for X to be ignored or not ignored?"

e.g., we could provide facilities more catered to the specific annotation and its effects (borrowing some example code from CPP ref):

struct Empty {}; // empty class
 
struct X
{
    int i;
    Empty e;
};
 
struct Y
{
    int i;
    @std::no_unique_address Empty e;
};
 

constexpr auto x = ^Y::e;
constexpr std::optional<std::no_unique_address> opt_nua_annot = single_annotation_of<std::no_unique_address>(x);

constexpr if (opt_nua_annot.has_value()) {
  constexpr std::no_unique_address nua_annot = *opt_nua_annot;

  constexpr if (nua_annot.layout_known_by_front_end()) {
    constexpr if (nua_annot.changes_layout()) {
      std::cout << "The layout of " << name_of(^T) << " has been changed in this build!\n";
    } else {
      std::cout << "The layout of " << name_of(^T) << " has not been changed in this build.\n";
    }
  } else {
    std::cout << "The layout of " << name_of(^T) << " may or may not be changed in this build. It's up to the back end.\n";
  }
} else {
  std::cout << "The layout of " << name_of(^T) << " has not been changed in this build.\n";
}

- Wyatt

On 16/10/2023 19.26, Wyatt Childers via SG7 wrote:

    [[deprecated]] struct foo {};
    /* implies */
    @std::deprecated() struct foo {};

If an implementation chooses to ignore the attribute,
does it mean the implication doesn't hold?

Jens