On Sun, Aug 27, 2023 at 7:25 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sun, Aug 27, 2023 at 11:45 PM Gašper Ažman wrote:
> >
> > What you want is not expressible *in the standard* without
> > decades of work nobody wants to do and nobody wants to implement
> > afterwards.
>
>
> What if we just had an extra sentence tagged onto 'Functions' under
> section 9.3.3.5 on page 182 as follows? It could be worded very
> generically, the compiler writers would get the jist of it.

The C++ standard does not exist to give people "the jist of it". It's
not an informal, hand-wavy "kinda like that" sort of document. It
specifies behavior, explicitly and clearly.

If you can't break it down into exact behavior, then it's not
something that can be standardized.

> 9.3.3.5 Functions
> 1 In a declaration T D where D has the form
> D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
> ref-qualifieropt noexcept-specifieropt verbose-specifieropt
> attribute-specifier-seqopt
> and the type of the contained declarator-id in the declaration T D1 is
> “derived-declarator-type-list T”, the type of the declarator-id in D
> is “derived-declarator-type-list noexceptopt verboseopt function of
> parameter-type-list cv-qualifier-seqopt ref-qualifier opt returning
> T”, where
> (1.1) — the parameter-type-list is derived from the
> parameter-declaration-clause as described below and
> (1.2) — the optional noexcept is present if and only if the exception
> specification (14.5) is non-throwing
> (1.3) — the optional verbose is present if the compiler

OK, stop right there.

If you search the standard, you will find that the word "compiler" is
found *nowhere* in normative text of the standard. It is occasionally
used in "Note" blocks of text or footnotes, but those are explicitly
not behavioural.

So the word you're looking for is "implementation". Which even for
compiled C++ is not *just* the compiler.

> is to disable all optimisations

And we have to stop again.

While the word "optimize" (or its derivations) does in fact appear in
normative text, these are generally used when referring to specific
circumstances. Copy elision for example.

To say "disable all optimizations" is therefore a meaningless
specification of behavior, as there is no sense of what those
"optimizations" might be which would be "disabled" by this switch.

> inside the body of the function, treating all
> objects as though they were volatile,

Define "all objects".

> not enforcing aliasing rules,

What are "aliasing rules"? The only normative mentions of the term
"alias" or its derivations are with regard to type aliases or
namespace aliases.

And if you're referring to the "strict aliasing rule" (the general
term used to refer to [basic.lval]/11 in C++20)... again, what does it
*mean* to "not enforce" the rule? This rule prevents you from, for
example, accessing an `int` through a glvalue of type `float`. Nowhere
in the standard is it defined what would happen if you tried to do
that. So if the rule preventing you from doing it were "not enforced,"
what *would* happen? What is the behavior that you are switching on?
And where is that behavior defined in the standard?

> and not eliding any comparisons or operations even if they appear to
> be redundant or to have undefined behaviour. For class objects of type
> 'volatile', the member function marked 'volatile' is the first choice
> to be invoked if it is accessible, otherwise any suitable member
> function not marked 'volatile' is invoked.

And what of non-member functions?