Hi,
On 2019-11-12 18:15:28 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > It's worthwhile to note - I forgot this - that noreturn actually has
> > been standardized in C11 and C++11. For C11 the keyword is _Noreturn,
> > with a convenience macro 'noreturn' defined in stdnoreturn.h.
>
> > For C++11, the syntax is (please don't get an aneurysm...):
> > [[ noreturn ]] void funcname(params)...
> > (yes, the [[]] are actually part of the syntax, not some BNF like thing)
>
> Egad. I'd *want* to hide that under a macro :-(
Yea, it's quite ugly.
I think the only saving grace is that C++ made that the generic syntax
for various annotations / attributes. Everywhere, not just for function
properties. So there's [[noreturn]], [[fallthrough]], [[nodiscard]],
[[maybe_unused]] etc, and that there is explicit namespacing for vendor
extensions by using [[vendorname::attname]], e.g. the actually existing
[[gnu::always_inline]].
There's probably not that many other forms of syntax one can add to all
the various places, without running into syntax limitations, or various
vendor extensions...
But still.
> > While it looks tempting to just use 'noreturn', and backfill it if the
> > current environment doesn't support it, I think that's a bit too
> > dangerous, because it will tend to break other code like
> > __attribute__((noreturn)) and _declspec(noreturn). As there's plenty
> > other software using either or both of these, I don't think it's worth
> > going there.
>
> Agreed, defining noreturn is too dangerous, it'll have to be
> pg_noreturn. Or maybe use _Noreturn? But that feels ugly too.
Yea, I don't like that all that much. We'd have to define it in C++
mode, and it's in the explicit standard reserved namespace...
> Anyway, I still like the idea of merging the void keyword in with
> that.
Hm. Any other opinions?
Greetings,
Andres Freund
