> On Sep 16, 2025, at 4:32 PM, Bill Wendling <[email protected]> wrote: > > On Tue, Sep 16, 2025 at 11:39 AM Yeoul Na <[email protected] > <mailto:[email protected]>> wrote: >> Hi folks, >> > Hi Yeoul, > >> I wanted to share some updates from our WG14 meeting in Brno, where we >> presented our proposal on dependent attributes. >> >> # Our Proposal >> >> We presented N3656 (www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf >> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf>), which >> introduces "Dependent Attributes" as a new category of attributes that need >> to reference other program entities (with __counted_by(len) as the primary >> example). The proposal defines two key behaviors for name lookup: >> >> Forward lookup (delayed parsing) to reference not-yet-declared structure >> members or parameters >> Direct member access using identifier names without prefixes >> >> # Voting Results >> >> After discussions, we put forward three questions to the committee: >> >> 1. Name lookup mechanism: Is WG14 in favor of the name lookup mechanism for >> dependent attributes proposed in N3656? >> >> Result: Weak in favor. More members voted in favor than against. Committee >> feedback indicated a desire for well-defined restriction rules for >> expressions within __counted_by and similar attributes to minimize potential >> issues with delayed parsing. >> >> 2. Diagnostics for name conflicts: Is WG14 against diagnosing name conflicts >> for array parameter size? >> >> int size; // name conflict - diagnose as potential mistake >> void foo(int arr[size], int size); >> >> Result: Strong direction for adding diagnostics. MISRA C already forbids >> such shadowing as error-prone. These diagnostics will help us understand how >> frequently this pattern occurs and its impact. >> >> 3. Forward declaration approach: Does WG14 want to see something along the >> lines of N3433 (www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf >> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf>)? >> >> Result: No consensus. More members voted against this approach, despite >> previous "along the lines" support. Several members changed their position >> due to the delayed parsing alternative and Clang's opposition to the forward >> declaration approach. >> >> # Next Steps >> >> Based on this feedback, we're proceeding with: >> >> ## Specification work: >> >> - Formalize restrictions for expressions in dependent attributes in the >> revised proposal >> - Submit a standard proposal specifically for bounds attributes (N3656 >> focused on name lookup rules rather than specific attributes) >> >> ## Implementation in Clang: >> >> - Add diagnostics for name conflicts in array parameter size, potentially >> proposing it as ill-formed if results support it. >> - Continue open-sourcing -fbounds-safety for features not dependent on >> complex expressions in counted_by. This will still allow adopting the >> annotation in most of the use cases. >> - Implement the proposed name lookup rule under an experimental flag with >> formalized restrictions to verify the approach in Clang. >> >> ## Seeking Community Input: >> >> I'd like to hear what the GCC/Clang community thinks about the idea of >> specifying formal restrictions for expressions within the attributes to >> support delayed parsing. Or should we still seek alternatives to avoid >> delayed parsing? Your feedback on this approach would be valuable as we move >> forward with the implementation. >> > Avoiding delayed parsing would be ideal, but as your paper pointed out it > won't be possible in all situations. I thought your paper made a very solid > case for the current syntax, which would require some form of late / delayed > parsing. Is it fair to assume that once you do the "specification work" then > the committee is inclined to accept your proposal?
This is a bit complicated. N3656 was not written to be added to the standard directly. Instead, we wrote it to get direction and advice from WG14, and to work with them on making a specification that compilers like GCC and Clang can implement. We got weak support in favor, which I took as encouragement to continue working in this direction. Some committee members even told us that since these are attributes, we can do what we want in the compilers. Based on this feedback, our near-term goal is to work on the specification and get some good committee members to review it, to make sure it makes sense and can be implemented in compilers like GCC and Clang. > > As an aside, I wrote a proof-of-concept patch for GCC that performs delayed > parsing. There was pushback because it didn't ensure the expression was > context-free, but that could be checked for and rejected accordingly. I point > this out to show that it's not necessarily an impediment to adoption as the > changes were relatively small. Oh interesting! So the GCC community wanted the expression to be context-free? Like only allowing a subset of expressions that are guaranteed to be context-free? We can work on specifying such a subset for the attributes. > > -bw
