If it is just for determining compilation error and both are applied, then it is fine.   Perhaps for more complex expressions (or instead) some constexpr code could make sense. E.g. consteval bool featureA = ...; consteval bool featureB = ...; [[FeatureA(featureA), FeatureB(featureB)]   [ An extreme example would have been a XOR attribute operator, where compilers supporting both attributes not know which one they should prefer. Perhaps the first one with "XOR shorthand execution", which would be similar to || shorthand, with differences in detail (like XOR definitely turning off the second attribute otherwise error and || keeping it optional, as long as the first attribute exists). ]   -----Ursprüngliche Nachricht----- Von:Marcin Jaczewski <marcinjaczewski86_at_[hidden]> Gesendet:Mo 24.03.2025 16:16 Betreff:Re: [std-proposals] Ignoring attributes An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; pon., 24 mar 2025 o 15:53 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> napisał(a): > > Please not. Those are not feature queries, but attributes. > But used for "features" like `pack` and if I have two compilers that have different names for the same functionality, how to express this in attributes? > > > What is [[no_unique_address || indeterminate]]? > I would say same as `[[no_unique_address, indeterminate]]` Beside it only should make sense with `!!` where we require some specific end result. If we are allowed to ignore any of the attributes then booleans operations are pointless. Technically the compiler could apply all attributes listed at once, `!!` is only to determine when ignoring attributes should be an error. ``` [[!!(DoA && NotDoA)]] [[!!(DoA || NotDoA)]] ``` Compiler knows both, and "ignorability" pass, but then compiler fails anyway as attributes contradict each other. > > > > > Also: > > !! should be well distinguished from NOT and logical operations > > One can interpret it as double negation, but do not introduce negation, too > Yes, it could be interpreted as "double negations" as sometimes do `!!expression`. Here I use it more as "exclamation bang" and they are doubled to not get confused with negation itself. But this is effective bikeshedding, any syntax that now fails to compile will be fine. > > -----Ursprüngliche Nachricht----- > Von: Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> > Gesendet: Mo 24.03.2025 15:37 > Betreff: Re: [std-proposals] Ignoring attributes > An: std-proposals_at_[hidden]; > CC: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>; > pon., 24 mar 2025 o 15:03 Andrey Semashev via Std-Proposals > <std-proposals_at_[hidden]> napisał(a): > > > > On 3/24/25 15:26, Marcin Jaczewski via Std-Proposals wrote: > > > > > > If we want not-ignorable attributes it should be explicit and know > > > upfront even if compiler is 10y old. > > > I would suggest change syntax a bit and add `!!` to attribute to mark > > > it required: > > > > > > ``` > > > [[!!no_unique_address]] int foo; > > > ``` > > > > > > or > > > > > > ``` > > > [[!!(gnu::packed, clang::packed)]] class Foo; > > > ``` > > > > > > If the compiler does not recognize and support any attribute from this > > > it should break compilation. > > > > This won't work because current compilers are required to ignore such > > attributes. > > > > If you want mandatory attributes, they should use a syntax that is > > invalid with older compilers. > > Whole point is that it is invalid now, GCC and Clang fail at parsing it. > They can't ignore that they can't parse correctly. > And when they start parsing this new format, they can obey rules that > standard will impose on `!!`. > > After sending previous email I think about this bit more and > come to conclusion that `!!( ... )`  should allow `&&` and `||` > as sometimes different compiler attributes could not overlap: > > ``` > [[!!( X::FeatureAB || (Y::FeatureA && Y::FeatureB) ) ]] class A; > ``` > > Now under compiler `X` it require one feature but on compiler `Y` two, > but combination of them make class ABI compatible with compiler `X` output. > > > > > -- > > Std-Proposals mailing list > > Std-Proposals_at_[hidden] > > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals > -- > Std-Proposals mailing list > Std-Proposals_at_[hidden] > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals > > -- > Std-Proposals mailing list > Std-Proposals_at_[hidden] > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals