On 04.08.25 20:29, Yeoul Na via Liaison wrote:
> Hi all,
>
> There have been challenges for implementing attributes, such as __counted_by for the bounds safety extension for C, because the language doesn’t allow forward referencing a parameter or a struct field, or referring to a field within the structure.
>
> To address this problem, we recently submitted a proposal to WG14 about “dependent attributes” in which forward referencing and unqualified name lookup for struct members in struct is allowed: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf>
>
> This paper will be discussed in Brno. Our goal is to designing rules that are acceptable both for C and C++, so the attributes can be used in headers shared between these languages. Hope this effort will allow major compilers like Clang and GCC to implement the compatible syntax and semantics in the long run, while still keeping the programming model widely usable.
>
> I was advised to run it by the C/C++ compatibility study group. I’d appreciate your feedback!

From a C++ viewpoint, I have the following remarks:

 - Since attribute syntax is not used throughout the paper,
it's hard to see where the potential future attributes would manifest
in the syntax space. For example, I would expect an attribute to
go after the declarator-id of a field, not after its pointer type.
But maybe my expectation is wrong.

 - For the function return type issue, C++ can put functions into
namespaces, e.g.

  int * __counted_by(n) N::M::f1(int n);

Traditionally, parameter names were not available for lookup in the
function return type, and neither was the function return type
considered in the scope of which the declarator-id is a member
(here: N::M). C++ invented late-specified return types for that:

  auto N::M::f1(int n) -> int * __counted_by(n);

I feel that making function parameter names available in the
traditional position of the return type would be too confusing
(does it also look into namespace N::M? Why not?)

 - Page 12: "typedef int * intptr_t;"
This confuses me because intptr_t means something different
in the C and C++ standards.

 - If I'm reading this correctly, you want different lookup
rules for expressions appearing in attributes on field members,
on function parameters, and on function return types. Is that it?
For field members, we already have machinery in C++ to delay-parse
some parts of structs/unions, so I expect no issues, unless
the presence of the attribute could impact other field declarations
in the struct. Without specific proposed attributes, it's hard
to say if e.g. recursive dependencies could occur.

Jens