On the proliferation std::format tricks: for better or for worse we're
going there anyway. The possible side-effects of a function that uses
reflection/code-generations facilities depend on the provided values of its
parameters, not just their types. In the next decade reflection will be
heavily (ab)used. And we will have to figure out how such code could be
debugged.

пт, 29 авг. 2025 г. в 17:22, Brian Bi <bbi5291_at_[hidden]>:

>
>
> 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*
>