Back from vacation, a few comments below. On Wed, Dec 17, 2025 at 6:04 PM Alejandro Colomar <[email protected]> wrote: > > Hi Aaron, > > On Wed, Dec 17, 2025 at 07:53:13AM -0500, Aaron Ballman wrote: > > I'm on vacation so my response will be somewhat short and I probably > > won't re-engage until January. More below. > > Thanks! > > > On Wed, Dec 17, 2025 at 5:57 AM Alejandro Colomar <[email protected]> wrote: > [...] > > > I agree with your analysis of all the other positions though. > > [...] > > > > [[fallthrough]] is an *aberration*. > > > > lol > > > > > It should have never been an > > > attribute, because, as you see, it doesn't attribute anything. > > > > It is an attribute-declaration. See 6.7.1p1 and p10. This was done to > > make the grammar a bit easier to understand, in C++ it's attributing a > > null statement instead. > > Neither of them are good, indeed. That's a consequence of trying to fit > an attribute into what really is a statement.
Attributes can be applied to statements, so I fail to see what the issue is here? > > > fallthrough is a jump statement misusing the syntax of an attribute. > > > > Incorrect. It is not a jump statement, it has no semantic effect. See > > 6.7.13.6 > > It is not defined by the standard to be a jump statement, but we could > perfectly define it as such if we wanted. And it would fit much better > than "an attribute to the null statement" or "an attribute declaration". I don't agree; when we start making non-jumps into jumps, we complicate things for no benefit (for example, we then have to think about every place we put constraints on jumps and targets and decide what to do with these non-jumps). > > > It should have been 'fallthrough;', with syntax similar to 'continue;' > > > et al.. What it does is best described as "jump to the next 'case'", > > > with a constraint that the statement must be the last statement at the > > > top-level of a 'case'. > > > > No, it really does not. It's a hint to the compiler saying "the > > semantics of this code is intended". It's not a jump to the next case > > in the same way that a semi colon is not a jump to the next statement; > > it's following the flow of execution laid out by the abstract machine. > > It is a jump statement, just like a return statement at the end of a > function that return void is a jump statement, or a continue statement > at the end of a loop is a jump statement too. Jump statements emit branching instructions, fallthrough (and semi colons) do not. > Both of those have no > semantics, and you can remove them without consequences; the difference > is that fallthrough is constrained to never have semantics. > > [...] > > > > I'm working on a proposal to fix attributes (see below) so that they're > > > not comments anymore. Aaron seems to be okay with that proposal. > > > > I have no idea where you got that impression, > > You and I discussed it in Brno (not in the meetings, but in the > corridors). > > > but it's not something > > I'm okay with; I think your proposal is an overreach into > > implementation QoI. > [...] > > I don't understand why now you claim that you're not okay with it. > Also, I don't agree that transforming UB into a constraint violation is > somehow an overreach into QoI. I am at a loss for where the confusion came from, I've *always* been adamant about the design principle that standard attributes are hints to the compiler and never anything more. (Note: implementation-defined attributes are not standard attributes, those are expected to do anything and everything an implementation desires.) That's been a principle of the feature since it was introduced into C++11. I know WG21 has tried to undo that with p2552r3, but that paper didn't actually change the status quo with its wording (and consequently, Clang isn't changing the implementation either; we're quite happy with our implementation and we have downstreams which rely on it). WG21 added an attribute that was not a hint to the compiler and it has been a mess that implementations are still dealing with five+ years later; I do not support following down the same path for C. ~Aaron > > > > > ~Aaron > > Have a lovely night! > Alex > > > > > > I've also CCed Joseph, who doesn't agree yet with it. > > > > > > I also want to write a proposal to make fallthrough a proper jump > > > statement. I floated the idea in the committee, and some members were > > > in favour of this, but I haven't written a paper yet. > > > > > > Ignoring fallthrough, the guidelines become consistent. > > > > > > > > > Have a lovely day! > > > Alex > > > > > > --- > > > Name > > > alx-0011r12 - diagnose unsupported attributes (Earthly Demon) > > > > > > Principles > > > - Codify existing practice to address evident deficiencies. > > > > > > Category > > > Attributes > > > > > > Author > > > Alejandro Colomar <[email protected]> > > > > > > Cc: Jens Gustedt <[email protected]> > > > Cc: Aaron Ballman <[email protected]> > > > Cc: Joseph Myers <[email protected]> > > > Cc: Alex Celeste <[email protected]> > > > Cc: Martin Uecker <[email protected]> > > > > > > History > > > <https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0011.git/> > > > > > > r0 (2025-04-01): > > > - Initial draft. > > > > > > r1 (2025-04-02): > > > - Add stdc:: attributes, and make them like vendor ones, in > > > that they're allowed to change validity and semantics of a > > > valid program. Revert changes to prefixless attributes. > > > Adapt names. > > > > > > r2 (2025-04-02): > > > - Add __stdc__:: variant. > > > - Fix typos. > > > - Make it a constraint violation to use an unsupported stdc:: > > > attribute. > > > - Define 'standard prefixed attributes'. > > > > > > r3 (2025-05-04; n3576): > > > - tfix. > > > - wfix. > > > - Rebase on n3550. > > > > > > r4 (2025-06-27): > > > - Reserve the standard prefixed attribute tokens. > > > - Support for them is optional, BTW. > > > > > > r5 (2025-06-30; n3631): > > > - Note that the last parenthetical of 6.7.13.1p1 is redundant > > > with a constraint specified in 6.7.13.2p2, and thus remove it > > > without replacement. > > > - Add a similar constraint for the standard prefixed > > > attributes. > > > - Change the proposal name to be more consistent with the > > > current proposal. > > > > > > r6 (2025-07-04): > > > - Fix incorrect uses of terminology. > > > - tfix. > > > > > > r7 (2025-07-04; n3661): > > > - Clarify sentence with context. > > > - tfix. > > > > > > Brno (2025-08): > > > - A. Ballman: [[stdc::attr]] is incompatible with C++. Better > > > fix [[attr]]. > > > > > > r8 (2025-09-04): > > > - Fix standard attributes, instead of adding a new kind of > > > attributes. This makes it compatible with C++, and also > > > significantly simplifies the proposal. > > > - Retitle; this is now almost a Ghost. > > > > > > r9 (2025-09-07): > > > - Diagnose all unsupported attributes. This is an Earthly > > > Demon. > > > > > > r10 (2025-09-11): > > > - Mention C++ p2552r3. > > > > > > r11 (2025-09-25): > > > - Remove paragraph. > > > > > > r12 (2025-12-01): > > > - tfix > > > > > > Description > > > Implementations are required to diagnose unrecognized standard > > > attributes. This is required by the constraint in 6.7.13.2p2: > > > > > > The identifier in a standard attribute shall be one of: > > > > > > deprecated fallthrough maybe_unused nodiscard > > > noreturn _Noreturn unsequenced reproducible > > > > > > However, they're not required to diagnose about recognized but > > > unsupported standard attributes. Or about unrecognized vendor > > > attributes. > > > > > > The situation in an implementation that entirely ignores > > > attributes is such that for example, uses of the [[deprecated]] > > > attribute, where a programmer explicitly wants uses of some > > > function to be diagnosed, they are not diagnosed at all. This > > > proposal would at least make the programmer aware that it won't > > > receive any diagnostics about uses of such attributed functions. > > > > > > But this gets even worse when dealing with vendor attributes. > > > A program written for one compiler could be silently transformed > > > into a different program by another compiler which chooses to > > > ignore the attribute without diagnosing its use. This is an > > > implicit Undefined Behavior that we need to remove. > > > > > > Most existing implementations, if not all, already diagnose > > > unsupported attributes. Let's make them all diagnose. It > > > should be easy. Just saying "Use of unsupported attributes" or > > > "attributes are not supported" would be fine, so it doesn't > > > impose any important implementation burden. The implementation > > > doesn't even need to parse the attribute token/s. > > > > > > C++ > > > C++ has a related proposal, p2552r3. > > > > > > <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2552r3.pdf> > > > > > > It essentially proposes three rules: > > > > > > - The First Ignorability Rule. > > > > > > > Standard attributes cannot be syntactically ignored. > > > > > > This is essentially covered by this proposal too. The > > > added constraint, which makes use of unsupported > > > attributes a constraint violation, and the removal of > > > the ambiguous sentence about ignoring attributes, > > > result in them being not syntactically accepted. > > > > > > The C++ proposal says that Clang mentioned > > > > > > > that mandating to check the syntax of standard > > > > attributes would be an unacceptable implementation > > > > burden in particular with regards to checking > > > > appertainment; > > > > > > This is where this proposal differs from C++'s. Under > > > my proposal, implementations are free to continue > > > ignoring the syntax within [[...]]. They don't need to > > > parse the attribute, as long as they produce a > > > diagnostic, which can be as simple as saying "Attributes > > > are not supported by this implementation". Such a > > > diagnostic is enough to protect programmers from the > > > danger of using code that is ignored by the > > > implementation, while keeping implementation burden down > > > to the bare minimum. Under this proposal, [[...]] is > > > essentially "token soup" (if the implementation decides > > > so), as called by the C++ proposal. > > > > > > - The Second Ignorability Rule. > > > > > > Keep the status quo. This is maintained by my proposal. > > > That's guaranteed by n3550::6.7.13.2p3: > > > > > > > A strictly conforming program using a standard > > > > attribute remains strictly conforming in the absence > > > > of that attribute. > > > > > > That text is not changed by this proposal. > > > > > > - The Third Ignorability Rule. > > > > > > The C++ proposal has two approaches. The first one is > > > the most reasonable one, and is the one which is > > > compatible with all of the existing wording of the > > > standard. > > > > > > n3550 says this for attributes: > > > > > > > The __has_c_attribute conditional inclusion expression > > > > (6.10.2) shall return the value 202311L when given > > > > nodiscard as the pp-tokens operand if the > > > > implementation supports the attribute. > > > > > > If an implementation reports such a value, it's telling > > > the programmer that the implementation supports the > > > attribute. And the attribute was only allowed to be > > > ignored if unsupported, so any other reading of the > > > standard would be self-inconsistent. > > > > > > My proposal follows the same. By removing the ambiguous > > > sentence about ignoring unsupported attributes, but > > > keeping the sentences about __has_c_attribute(), we keep > > > this status quo. > > > > > > So, my proposal seems to be consistent with p2552r3 regarding > > > rules 2 and 3, and seems to be preferable regarding rule 1, at > > > least according to Clang. > > > > > > Proposed wording > > > Based on N3550. > > > > > > 6.7.13.1 Attributes :: Introduction > > > @@ p2 > > > Support for any of > > > the standard attributes > > > specified in this document > > > is implementation-defined and optional. > > > For an attribute token > > > (including an attribute prefixed token) > > > not specified in this document, > > > the behavior is implementation-defined. > > > -Any attribute token > > > -that is not supported by the implementation > > > -is ignored. > > > > > > 6.7.13.2 Attributes :: General > > > @@ Syntax, p1 > > > -standard-attribute: > > > - identifier > > > > > > ## The above is moved into 6.7.13.2+1 "Standard attributes". > > > > > > @@ Constraints, p2 > > > -The identifier in a standard attribute > > > -shall be one of: > > > - deprecated maybe_unused noreturn > > > unsequenced > > > - fallthrough nodiscard _Noreturn > > > reproducible > > > > > > ## The above is moved into 6.7.13.2+1 "Standard attributes". > > > > > > @@ Constraints, new p2+1 > > > +A program shall not use an attribute > > > +that is not supported by the implementation, > > > +except as an argument to > > > +the <b>__has_c_attribute</b> conditional inclusion expression. > > > > > > > > > 6.7.13.3..6.7.13.8 > > > ## Move these subsections to under 6.7.13.2+1 'Standard > > > attributes'. > > > > > > 6.7.13 Attributes > > > @@ > > > +6.7.13.2+1 Standard attributes > > > + > > > +Syntax > > > +1 > > > +standard-attribute: > > > + identifier > > > + > > > +Constraints > > > +2 The identifier in a standard attribute > > > + shall be one of: > > > + deprecated maybe_unused noreturn > > > unsequenced > > > + fallthrough nodiscard _Noreturn > > > reproducible > > > > > > ## The above is moved from 6.7.13.2p1,2 > > > > > > ## 6.7.13.3..6.7.13.8 are moved here as sub-clauses. > > > > > > -- > > > <https://www.alejandro-colomar.es> > > -- > <https://www.alejandro-colomar.es>
