On Fri, Aug 29, 2025 at 10:22 AM Brian Bi via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> 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.
>
> This was really intriguing. I'm very familiar with the first two, but I
don't know what "the `std::format` trick" refers to, and naive Googling
didn't show me a good reference. Can you please either explain more, or
else link to a reference that explains what you mean?


> #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*
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>