I have something to add.
Consider a C++ program with that requires a constant expression which
contains a non-trivial loop (one that cannot be analyzed easily, or at all,
possibly because whether or not it terminates depends on the same
analysis that the compiler performs, which is itself possible to write ).
If the loop terminates, its a core constant expression. If it does not, it
isn't a core constant expression, because it contains core language
undefined behaviour.
It would be impossible for the compiler to determine over
all potential constant expressions which are and aren't a constant
expression based on these rules. Such a check would be uncomputable, see
https://en.wikipedia.org/wiki/Halting_problem.
This means that, in the presence of infinite loops being UB, there exist
strictly conforming C++ programs which cannot be correctly compiled by any
implementation, for the same reason that no algorithm exists for the
halting problem (under the assumption the compiler for all C++
implementations are running on something which is as good as a turing
machine).

On Mon, May 11, 2020 at 14:22 Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, 11 May 2020 at 21:00, Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Sunday, 10 May 2020 18:02:15 PDT connor horman via Std-Proposals
> wrote:
> > > Though that leaves room for a lower level language, C or even Rust
> (which
> > > also has a valid infinite looping construct loop{}, which the fact it
> is
> > > infinite is relied upon for soundness).
> > >
> > > I would argue that where a user intends to invoke an infinite loop, and
> > > that intention is clearly communicated (condition of
> for/while/do-while is
> > > either a contextually converted constant expression of type bool, which
> > > after conversions evaluates to true, or the condition of for is
> omitted),
> > > the construct should be permitted. It harms embedded use cases (what
> about
> > > processors that don't have a STP instruction); can be surprising for
> people
> > > coming into C++ from other languages that do have endless looping
> > > constructs, including C; and even serves to limit the common subset
> between
> > > languages further.
> >
> > The problem is that we've so found far exactly one valid use-case for an
> > infinite loop without any visible progress and it's really, really rare.
> I
> > don't think the language needs to change to accommodate it, if there are
> other
> > solutions and if even C++ can do that by having a library function do it.
> >
> > This function could be called "exit".
>
> P1494 covers this problem in addition to others. We don't need to
> invent anything that hasn't already
> been invented, and proposed, too.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>