On 24/09/2021 12.46, Gabriel Dos Reis wrote:
> An attribute appertaining to a type does not actually modify that type. Like you said, it applies to the declarations using that type. We don't have a notion of making a new type by merely applying an attribute to an existing type.
>
> The notion of "attribute appertaining to function type" has always been a curiosity, more as a specification device than a fundamental programming notion.

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.

> Even if one takes the view that contracts should be part of the type (which I don't recommend because that opens up a whole different kind of can of worms), the notion of "attributes appertaining to function type" doesn't create an actual conflict, because the position of those contract notations are exactly where they should be in that context.

That viewpoint seems to imply that

using F = int(int f) [[contract stuff]];

should be valid. I don't think this syntax is being proposed as valid.

> Finally, for a well-formed program with well-defined behavior fed with the correct data, ignoring contracts (with diagnostics, if one wishes) would be a correct (if poor quality) implementation.

That seems an interesting observation. The discussion so far seems to have
assumed that contracts are not ignorable in the attribute sense.

Do the other contracts people agree with that observation?

Jens