C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] labels

From: Niall Douglas <s_sourceforge_at_[hidden]>
Date: Tue, 11 Aug 2020 15:46:07 +0100
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.

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.

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

Received on 2020-08-11 09:49:34