Am Dienstag, den 11.08.2020, 15:46 +0100 schrieb Niall Douglas via Liaison:
> On 11/08/2020 13:26, Jens Gustedt via Liaison wrote:
>
> > > > Is there any chance that you might propose C standardising computed
> > > > gotos? Then Python on MSVC goes +30% faster. You would, quite
> > > > literally, save millions of kWh of wasted electricity in the next
> > > > few decades.
> > >
> > > I will put it on my list... I think the type should
> > > not be void* for labels. Maybe:
> > >
> > > noreturn void (*addr)(void);
> >
> > 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.
>
> But I have additional rationale. We have an optimisation problem where
> if there were a class of function pointer types which can never return,
> we could easily solve poor optimisation problems such as:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95001
>
> https://bugs.llvm.org/show_bug.cgi?id=45839
>
> What would happen here is that abort(), being marked [[noreturn]], would
> gain a function pointer type which can never return. This function
> pointer type would also suit labels.

This is actually what I tried to suggest...

> My proposed syntax for never returning invocable pointers would be:
>
> _Noreturn_t (*addr)(args...)
>
> ... where the builtin _Noreturn_t type means that this function will
> never, ever, return. _Generic etc can select on that, obviously.

This is the correct approach. I am not sure about the naming
of the return type, but this is essentially the bottom type
we are missing (void is more like the unit type).

> If C++ maps this C facility, they no doubt would choose std::noreturn_t,
> which no doubt would quack like void, but not be, void, so all the
> metaprogramming remains happy e.g. std::is_void_v<std::noreturn_t> would
> be true.
>
> Niall


Best,
Martin