Is the standard now defining object layout in a way that ensures what the value should be when [[no_unique_address]] and how to check for the correct value?

-- Gaby

-----Original Message-----
From: Core <core-bounces_at_[hidden]> On Behalf Of Aaron Ballman via Core
Sent: Tuesday, February 7, 2023 12:16 PM
To: Timur Doumler <cpp_at_[hidden]>
Cc: Aaron Ballman <aaron_at_[hidden]>; Robert Seacord <rcseacord_at_[hidden]>; Evolution Working Group mailing list <ext_at_[hidden]>; Timur Doumler via Core <core_at_[hidden]>; Liaison_at_[hidden]
Subject: Re: [isocpp-core] Ignorability of attributes: draft wording, and concern about __has_c_attribute

On Tue, Feb 7, 2023 at 2:11 PM Timur Doumler <cpp_at_[hidden]> wrote:
>
> (removing SG1 from this thread)
>
> Robert, thanks for the clarification. I would be very curious how exactly WG14 defines this idea of "implements the semantics suggested in the specification of the attribute". Is this what the C23 working draft actually says now?

Our editors haven't produced a new working draft yet that incorporates
CD ballot comment resolutions, but the wording of each attribute will
say:

"The __has_c_attribute conditional inclusion expression (6.10.1) shall
return the value <blah> when given <yada> as the pp-tokens operand if
the implementation supports the attribute." The intent of "supports
the attribute" is "implements the recommended practice so the
attribute does the useful thing users expect it to do." It is
purposefully vague rather than trying to nail anything down because
attributes are inherently a matter of QoI, so it's up to the
implementation to decide whether they "do the useful thing users
expect".

> Aaron, would you be available this week? The EWG chair indicated yesterday that there might be time slots available for bringing this paper back to EWG this week.

I'm available at various times this week; mornings work better for me
than afternoons (Issaquah time).

FWIW, I think the current EWG direction is a problem. Consider:

struct Empty {};

struct Whatever {
#if __has_cpp_attribute(no_unique_address)
[[no_unique_address]]
#endif
  Empty E;
  int Val;
};

If the implementation is required to return true despite not
implementing the semantics of the attribute, it (effectively) can
never implement the semantics of that attribute without introducing a
silent ABI break. In my experience, users care whether an attribute
does what it says on the tin and they use __has_cpp_attribute to tell
them that. Poll 2 breaks that expectation and leaves the programmer
with no alternatives.

> Simultaneously, it was my impression yesterday that EWG thinks Poll 1 is not a reasonable or feasible direction, as we have no way of defining what those "useful" or "observable" semantics would be that are required for __has_cpp_attribute to return a positive value in the Poll 1 scenario.

Attributes themselves (the bits within the [[]]) are not portable,
even for the standard attributes. The recommendation is that
implementations implement the standard attribute and its recommended
practices. If the implementation feels that they've done that, they
should return the expected nonzero value for that attribute. If they
don't feel like they've done that, they should return zero. To me,
this is solidly QoI and EWG doesn't need to define anything there.
However, I also wasn't able to make it to the EWG discussion of this
topic, so perhaps there's nuance I'm not getting from the meeting
minutes.

~Aaron

>
> Cheers,
> Timur
>
> On 7 Feb 2023, at 11:07, Robert Seacord <rcseacord_at_[hidden]> wrote:
>
> response inline below
>
> On Tue, Feb 7, 2023 at 10:50 AM Timur Doumler <cpp_at_[hidden]> wrote:
>
>>
>> @SG22: Can you confirm this? What is the intent of __has_c_attribute in C: what Poll 1 says or what Poll 2 says?
>
>
> The intent in C is the same as Poll 1:
>
> __has_c_attribute should return a positive value for a standard attribute only if it implements the semantics suggested in the specification of the attribute.
>
> The C Standard contains the following example in Subclause 6.10.1 Conditional inclusion, paragraph 17:
>
> /* Fallback for compilers not yet implementing this feature. */
> #ifndef __has_c_attribute
> #define __has_c_attribute(x) 0
> #endif /* __has_c_attribute */
> #if __has_c_attribute(fallthrough)
> /* Standard attribute is available, use it. */
> #define FALLTHROUGH [[fallthrough]]
> #elif __has_c_attribute(vendor::fallthrough)
> /* Vendor attribute is available, use it. */
> #define FALLTHROUGH [[vendor::fallthrough]]
> #else
> /* Fallback implementation. */
> #define FALLTHROUGH
> #endif
>
>> How should we resolve this contradiction? Should we re-discuss that aspect of the paper in EWG, with someone from SG22 present?
>
>
> Aaron Ballman would be the ideal person to represent the SG22 and WG14 positions, but if he is not available I would be willing to act as a poor substitute.
>
> rCs
>
>
_______________________________________________
Core mailing list
Core_at_[hidden]
Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=05%7C01%7Cgdr%40microsoft.com%7Cef49fe24777d4bf330d908db094825ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113977709526341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iHReReMMmXHHGXbVW0mLoIHyLSZrLf7hg3N%2BP4WiAnw%3D&reserved=0
Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2023%2F02%2F13839.php&data=05%7C01%7Cgdr%40microsoft.com%7Cef49fe24777d4bf330d908db094825ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113977709526341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=THyoFLfFXSqm%2FVtbsEXHM7ByWe0f5YtOlA1mYuY8tjc%3D&reserved=0