-
Notifications
You must be signed in to change notification settings - Fork 0
Open

Description
Hello! I hope it's okay to post it here. I'm sorry if this is not a right place for such discussions. I want the following changes to be "considered":
- Make
constexpr
function parameter mean what is currently described as "Maybe Constexpr". Possibly allowconsteval
function parameters with meaning "Strictly Constexpr". I believe that "maybe constexpr" is significantly more useful and flexible, and it's trivial to turn it into "strict" one by static_assert, but not the other way around. - Remove overloading based on constexpr-ness of the parameters. Reasons:
- Overloading rules are already too complex.
- We already have
if constexpr
which solves many problems very elegantly. The paper provides example of implementingstd::is_constant_expression
with overloading. But it does not justify overloading, sincestd::is_constant_expression
can also be implemented as a compiler builtin. - Overloading does not scale well. It "seems fine" if only one parameter may or may not be constexpr. But if a function has, for example, 8 such parameters, and we want to overload it based on each possible combinations, we need to provide 256 different overloads.
- Add
consteval
operator to the language, instead ofstd::is_constant_expression
in STL. It's shorter, but there is probably no other motivation about it. The meaning remains the same. - Consider adding
constexpr NSDM
with similar meaning tomaybe constexpr
parameters. At least for aggregates, it seems to combine nicely with CTAD. This is a very rough example.
template <>
struct data {
constexpr int x;
constexpr int y;
constexpr int z;
};
void foo(int x, int y) {
data x1{x, y, 0}; // Only two data members are initialized as NSDM, z is static constexpr.
static_assert(sizeof(x1) == sizeof(int) * 2);
static_assert(x1.z == 0);
}
Thanks!
Metadata
Metadata
Assignees
Labels
No labels