[Interest] Future of constexpr in Qt?

[Volker Hilsheimer]

> On 22 Nov 2024, at 17:14, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Thursday 21 November 2024 23:14:30 Pacific Standard Time Schimkowitsch 
> Robert wrote:
>> Herb Sutter highlighted constexpr as a way to increase programming language
>> safety in his recent keynote at Meeting C++. Things like making a runtime
>> function constexpr, so you can, at compile time, check for UB using
>> static_asserts or such when feeding it with various ranges of values (min,
>> max, zero, empty list,...). Now I'm thinking about how we could apply those
>> ideas in real code - and Qt mostly stops us from doing that, right there
>> and then.
> 
> That's a fallacy.
> 
> The fact that you can do it under constexpr doesn't magically make the same 
> usage safe when not under constexpr.

Also, some things that are constexpr in a test might not be constexpr in a real program. E.g. std::string can only be constexpr as long as the string fits into whatever size the library uses for its small-string optimization. As soon as that space is not sufficient, std::string has to allocate using operator new, and your code will no longer build.


E.g:

#include <string>

static constexpr std::string data("abcdefghijklmno");
static_assert(data.data() != nullptr, "String must be valid");


See how long that string literal can be until this no longer compiles (and not because the static assert fails). With both gcc and clang trunk, and -std=c++26, another character breaks the build - not because of the static_assert, but because the “data” variable is no longer initialized by a constant expression.

Volker

PS: which is why for the JNI improvements in the recent Qt releases we cooked up a true, but very limited, compile-time string type in https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qjnitypes_impl.h#n20, which is then also nicely tested using compile-time asserts in https://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/kernel/qjnitypes/tst_qjnitypes.cpp - so I very much sympathise with the idea. For type authors, this can be a very good unit-testing tool; but perhaps not so much for code using those types.