[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, 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?

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

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

That is not being proposed in the MVP. The notion was discussed in prior, C++20 era proposals, in particular in connection with declaration of pointer to functions and possible "conversions" (if they wee part of the type). I don't suggest that the MVP rushes into that complexity. However, we have to keep in mind that this is an MVP designed with an eye towards possible expansions/extensions and we want a coherent model.

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

That observation was at the basis of the current syntax, suggested going all the way back to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0287r0.pdf

We are designing contracts not so much for the correct programs behaving correctly (like I said, you can ignore contracts for them and they will continue to do just fine.) We are designing contracts as a mitigation measure for the misbehaving programs. Quoting the introduction of the above paper:

>>> Contracts are not a general error reporting mechanism, nor are they substitute for testing frameworks.
>>> Rather, they offer a basic mitigation measure when a program goes wrong because of mismatch of
>>> expectations between parts of a program.

-- Gaby

-----Original Message-----
From: Jens Maurer <Jens.Maurer_at_[hidden]>
Sent: Friday, September 24, 2021 6:20 AM
To: Gabriel Dos Reis <gdr_at_microsoft.com>; sg21_at_lists.isocpp.org; Aaron Ballman <aaron_at_aaronballman.com>
Cc: WG14/WG21 liaison mailing list <liaison_at_lists.isocpp.org>
Subject: Re: [isocpp-sg21] [wg14/wg21 liaison] Telecon to review P2388R1 Minimum Contract Support: either Ignore or Check_and_abort

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