Am Dienstag, den 11.08.2020, 17:31 +0200 schrieb Jens Gustedt via Liaison:
> Niall,
>
> on Tue, 11 Aug 2020 15:46:07 +0100 you (Niall Douglas via Liaison
> <liaison_at_lists.isocpp.org>) wrote:
>
> > On 11/08/2020 13:26, Jens Gustedt via Liaison wrote:
> > > If we want this, I really would like that to be a type that is
> > > outside of the current type system.
> >
> > I was, quite literally, just about to give the same feedback.
> > ...
>
> Since I am not sure that I understood if you were pro or against using
> that function type for labels.
>
> My argument is that a label is not a function entry point, and so we
> should never use a function pointer type for this, be the function
> type beneath how ever it may. The mechanics of function call don't
> apply, and the `noreturn` would mean very different things for labels
> than for function calls.

I wonder why you think this is the case? From a theoretical
point of view, as well as from practical experience, I do not
see why a function that does not return and a target of
goto could not be treated in the same way. Tail calls are
also often compiled into jumps.

(Of course, _Noreturn turns off tail-call optimization on
some common compilers, but this is for other reasons)

> Nobody should ever try to use a label and apply a function call
> operator, and this is best achieved if this whole "thing" would be a
> new type "label_t" or so that could just be used as I
> described. Implementations may well chose to have the same
> representation as an object or function pointer, but that's their
> business, not ours.

Actually, it would be nice to require a 'goto' to call
this special non-returning functions... I would like to see
such calls marked clearly in the code.

(I am also ok with label_t as this a risk-free design).

> That not withstanding, maybe there should be something done with
> pointers to functions that can't return. But that's a completely
> different issue, I think, and would deserve a different $SUBJECT.

Best,
Martin