On Thu, 2023-05-04 at 10:47 +0300, Lauri Vasama via Std-Proposals
wrote:
> Floating an idea i've been toying around with for a while concerning
> a new syntax for attributes with observable effects on program
> behaviour.
>
> https://vasama.github.io/wg21/Dxxx1
>

Hi,

I like the proposal. However, I don't think it makes sense to have each
attribute in both optional and mandatory flavour. What's the semantics
of [[!likely]]?

It might make sense to have both [[no_unique_address]] and
[[!no_unique_address]] at first glance, but in my mind these are two
distinct attributes. And I believe the suggestion is that MSVC would
have a different effect for the second one.

So I suggest to make the '!' character semantically part of the name of
the attribute, with the additional effects of these attributes not
being ignorable. This may resolve the issue with __has_cpp_attribute,
maybe you could query __has_cpp_attribute(!name) to check if [[!name]]
is available. I'm not how it fits into the compiler magic grammar, but
probably implementable.

I also think that "no_unique_address" is a horrible name, but this is
just bike shedding. I think the name should reflect the intent of using
the attribute. The intent is to reduce the size of the parent class by
potentially overlapping the member with other members. The subobject
not having a unique address among other subobjects is a side effect
that most people don't care about. So maybe make the mandatory version
of this [[!overlap]] or [[!may_overlap]]. This should be a separate
proposal though.

I think your proposal is valuable to reserve grammar space for
grammatical constructs that:
* fit well into the grammatical construct of attributes
* makes no sense to ignore
* would otherwise need to introduce a keyword, which always risks
collision with existing identifiers

Having said that there might be better options to reserve syntactic
space for new keywords, as [[!...]] is arguably a bit ugly for that,
and I'm also not a fan of co_* either.

Zig for example reserves @<name> for its builtin functions. C++
reserves __<name>, IMO this is uglier.

Cheers,
Lénárd