On Fri, Aug 29, 2025 at 9:29 AM Григорий Шуренков via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Oh, I thought that everybody wanted constexpr parameters, but nobody knows how to approach them.

From a library user perspective it should be easier to pass a constant to a function and not to worry that you need to wrap it into some template that captures its value.

In current C++ there are basically three ways to pass in a compile-time constant:

as a template argument (in angle brackets),
using an ordinary function argument whose type encodes the compile-time constant (for which one or more corresponding template arguments will be deduced), or
using the `std::format` trick.

#3 can occasionally have significant advantages over #1 and #2. The reason why `std::format` is designed that way is to reduce the number of template instantiations and therefore the compile-time cost. You want to be able to check the format string at compile time, but you don't need to use the content of the format string to determine what to instantiate. As soon as you need to use a compile-time constant to determine what to instantiate, you have to use #1 or #2.

The desire for constexpr parameters generally stems from the desire to be able to use the syntax of #3 together with the functionality of #1. In other words passing an argument to a constexpr parameter would be like passing a template argument in angle brackets, just with slightly different syntax.

I think that whether or not an argument is required to be a compile-time constant and can cause the implementation to do something different at compile time is an important part of a function's API, so making constexpr parameters look the same as regular parameters is not actually a benefit, and can actually make the code harder to read. So what are the actual benefits of constexpr parameters?

There are two cases that give a significant ergonomic benefit. The first is that of constructors, because an explicit template argument list can't be supplied to them. But in that case you already have the possibility of writing a factory function as a workaround. The other is when you're forced to write the `template` keyword in order to be able to use the angle brackets, because you're calling a member function template of a dependent type. I don't do that very often, but I suppose there are some people who do.

The reason why the feature is a hard sell is that it's adding novel syntax for something that is not actually that useful.

And If you have constexpr parameters you can imagine being able to overload a function on parameter "constexpr"-ness, which is currently impossible
(e.g. std::views::take that returns a view with number of taken elements encoded in type vs current version that have to store it in range).

I can see how this would be beneficial, but it would make the feature much more complicated to specify.

Also, consider what would happen if the `std::format` trick were proliferated: it would make debugging compilation errors in metaprogramming-heavy libraries much harder, because changing the value of a function parameter (not just its type and value category) could affect what happens at compile time. At least `std::format` always requires a constant expression for its first argument; you make the problem much, much worse if you allow overloading on constantness as well as if you make this feature easy to use. (Also, at least if you can't figure out why your `std::format` call doesn't compile, you can replace it with `vformat` and use the debugger to see what's going on right before the `format_error` exception gets thrown.)

With reflection standardized, we will have an explosion of consteval functions in user code, and users probably would prefer to have them as functions not as explicit function templates.

Regards,
Gregory

пт, 29 авг. 2025 г. в 15:46, Robin Savonen Söderholm via Std-Proposals <std-proposals@lists.isocpp.org>:
Why not just use "Non Type Template Parameters"? I've understood it so that you have a lot more powerful things you can do with those in newer standards, from template template to "auto".
For example, the following code is legal in C++-20 today:
template<std::integral auto sz>
std::array<decltype(sz), sz> foo () { return {}; }

On Fri, Aug 29, 2025, 14:02 Григорий Шуренков via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Hello!

The idea of constexpr parameters is floated from time to time, but I don't remember any proposals related to them.
The constexpr parameter is a parameter to a function that acts as a constexpr variable (including the possibility to use it as a template argument).
The value of constexpr parameter may influence the return type of the function.

Is anybody working on any such proposal now?

I also remember someone saying that constexpr parameters are incredibly hard to fit into current C++.
However, if we agree that a function with constexpr parameters should be an (implicit) template
(which is hard to swallow, but I don't see any other option...), is it really that difficult?

Regards,
Gregory

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Brian Bi