On Wed, Feb 8, 2023 at 9:30 AM Gabriel Dos Reis via Liaison <
liaison_at_[hidden]> wrote:

> 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?
>

I'd like to discuss this separately from __has_c_attribute.
It's confusing the resolution we're trying to do to IMO. I think there's
some upset about exactly no_unique_address, and it's bleeding into the rest
of the discussion.



> -- 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
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/02/1149.php
>