On Fri, Aug 29, 2025 at 9:29 AM Григорий Шуренков via Std-Proposals <
std-proposals_at_[hidden]> 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:

   1. as a template argument (in angle brackets),
   2. using an ordinary function argument whose *type* encodes the
   compile-time constant (for which one or more corresponding template
   arguments will be deduced), or
   3. 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_at_[hidden]>:
>
>> 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_at_[hidden]> 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_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*