Hi, On 2019-11-12 18:15:28 -0500, Tom Lane wrote: > Andres Freund <and...@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
