On Saturday, 6 May 2023 04:33:13 PDT Marcin Jaczewski via Std-Proposals wrote:
> https://gcc.godbolt.org/z/Gxqs6v331
> Interesting old MSVC reconginse this attribute but fails on assertion, new
> one will say that it does not recognize this attribute.

The assertion is your making an assumption of what the attribute will do, like
assuming that code after a [[noreturn]] will get dead-code-eliminated or that
[[assume]] informs the optimiser.

But that's not the question I understood you'd asked. I thought you'd wanted
to make sure that the user of your code wouldn't accidentally get an ABI
mismatch when compiling their code against a pre-compiled yours. If the
compiler isn't changing ABI, then there's nothing wrong with the test I
supplied.

If you want to achieve a particular layout, then you're making assumptions
about the ABI. In that case, you can just do a more extensive #if to accept or
reject, because you've certainly stepped far outside the standard. Or, like
you've shown, you can test for the effects and either reject that compiler or
use an alternative solution (like EBO).

Can you tell me off the top of your head what the size of TypeAndFlags is?
(let's assume a 64-bit little-endian architecture)
  enum class Type : unsigned short {};
  struct TypeAndFlags {
      uintptr_t isExtended : 1;
      Type type : 15;
      uintptr_t reserved : sizeof(void*) * 8 - 16;
  };

> If we `__has_cpp_attribute` interpreted as "I implement this attribute
> functionality", then yes, we could use this macro.
> But if it means "I know that attribute exists" like older MSVS did,
> then we could not use it.

But it *does* implement the functionality. It applied all of the ABI changes
that the ABI documents required of it. All zero of them.

As I said above: you want a way to test that the ABI has a visible effect with
the attribute. And you showed code that can detect it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering