Hi Aaron,


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

Great. JF said we can have a slot this morning. I hope to see you there!

> 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;
> };

I think this is a great code example to illustrate the disconnect that wehave here.

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

You are assuming here that there are only two alternatives: either the attribute "does what it says on the tin" (is "useful") or it doesn't. At the heart of the issue is that this is actually not a yes/no question, and does not always have a yes/no answer for many (most?) attributes. For example, it would be a perfectly standard-conforming implementation of [[no_unique_address]] if its semantics (= the subobject is overlapping) only kick in during a certain phase of the moon, or only if the name of the object starts with the letter 'q'. What do you return from __has_cpp_attribute then?

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

Exactly, So if you, as the user, rely on whether or not the semantics of the attribute kick in, and whether or not they will break your ABI, you have already lost, regardless of how __has_cpp_attribute is specified.

On the other hand, whether the compiler can recognise, parse, and syntax-check a standard attribute *is* a meaningful yes/no question, so if we want __has_cpp_attribute to do something useful, that is the one useful thing that we can specify it to do. Perhaps C should reconsider their direction on this one?

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

This seems like the only viable alternative: to leave it vague what it means to "support" an attribute, and to live with the current implementation divergence. But then I don't think you will be able to rely on code like your snippet above to behave the way you expect.

Cheers,
Timur