On 24/09/2021 17.23, Gabriel Dos Reis wrote:
> [Jens]
>> I don't agree. Something like "[[gnu::fastcall]]" seems very much attached
>> to the function type. In particular, a type mismatch in a function call
>> with respect to that attribute is likely going to cause a crash.
>
> However, that is notion is completely outside the standards. The standards don't even acknowledge that you can have a new function type by adding a calling convention,

Sure it does.

extern "C" void f();
extern "C++" void g();

declare functions of different types that are distinguishable by
overload resolution (for example). Almost nobody implements that, because
people are so used to having these interchangeable (and the calling
conventions are often the same), but that's not conforming.

> nor they even say that you can add an attribute to construct such a type. The whole notion of "appertaining to a function type" is left undefined. Can you overload on it? Can you template-argument deduce it? How do they behave with respect to std::same_as?

All questions that vendor extensions that do allow type-changing
attributes such as [[gnu::fastcall]] need to answer, agreed.
That's not much different from introducing SIMD types as
vendor extensions; the vendor also needs to specify how they
fit into the type system.

> (As an implementer who had to deal with the reality of calling conventions, it is not even a path that I would recommend the committee takes.)

It is my understanding that language linkage embodies differences in calling
conventions since C++98.

Jens