Date: Tue, 11 Aug 2020 17:31:35 +0200
Niall,
on Tue, 11 Aug 2020 15:46:07 +0100 you (Niall Douglas via Liaison
<liaison_at_[hidden]>) 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.
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.
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.
Jens
on Tue, 11 Aug 2020 15:46:07 +0100 you (Niall Douglas via Liaison
<liaison_at_[hidden]>) 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.
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.
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.
Jens
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2020-08-11 10:35:05