I think one of the important properties of this draft proposal is that older compilers can reject so-far unknown mandatory attributes. If an unknown attribute starts with !, fail, if not, ignore. That makes it important to have a clear general grammar space for those.   Bikeshedding: Perhaps     [[!!no_unique_address]] with two exclamation marks is clearer in that no (odd-numbered) negation is meant ...   -----Ursprüngliche Nachricht----- Von:Lénárd Szolnoki via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 05.05.2023 16:27 Betreff:Re: [std-proposals] [Draft Proposal] Required attribute syntax An:std-proposals_at_[hidden]; CC:Lénárd Szolnoki <cpp_at_[hidden]>; Lauri Vasama <wg21_at_[hidden]>; On Thu, 2023-05-04 at 10:47 +0300, Lauri Vasama via Std-Proposals wrote: > Floating an idea i've been toying around with for a while concerning > a new syntax for attributes with observable effects on program > behaviour. > > https://vasama.github.io/wg21/Dxxx1 > Hi, I like the proposal. However, I don't think it makes sense to have each attribute in both optional and mandatory flavour. What's the semantics of [[!likely]]? It might make sense to have both [[no_unique_address]] and [[!no_unique_address]] at first glance, but in my mind these are two distinct attributes. And I believe the suggestion is that MSVC would have a different effect for the second one. So I suggest to make the '!' character semantically part of the name of the attribute, with the additional effects of these attributes not being ignorable. This may resolve the issue with __has_cpp_attribute, maybe you could query __has_cpp_attribute(!name) to check if [[!name]] is available. I'm not how it fits into the compiler magic grammar, but probably implementable. I also think that "no_unique_address" is a horrible name, but this is just bike shedding. I think the name should reflect the intent of using the attribute. The intent is to reduce the size of the parent class by potentially overlapping the member with other members. The subobject not having a unique address among other subobjects is a side effect that most people don't care about. So maybe make the mandatory version of this [[!overlap]] or [[!may_overlap]]. This should be a separate proposal though. I think your proposal is valuable to reserve grammar space for grammatical constructs that: * fit well into the grammatical construct of attributes * makes no sense to ignore * would otherwise need to introduce a keyword, which always risks collision with existing identifiers Having said that there might be better options to reserve syntactic space for new keywords, as [[!...]] is arguably a bit ugly for that, and I'm also not a fan of co_* either. Zig for example reserves @<name> for its builtin functions. C++ reserves __<name>, IMO this is uglier. Cheers, Lénárd -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals