FWIW, it seems to be possible to turn function parameters into constants
using reflection, though it's very possibly just a quirk of the current
clang implementation:

    #include <meta>

    template <auto X, auto Y>
    constexpr void
    static_assert_equal_impl () {
        static_assert (X == Y);
    }

    constexpr void
    static_assert_equal (auto x, auto y) {
        extract<void (*) ()> (
            substitute (
                ^^static_assert_equal_impl, {
                    std::meta::reflect_constant (x),
                    std::meta::reflect_constant (y)
                }
            )
        ) ();
    }

    int main () {
        static_assert_equal (1, 1); // ok
        static_assert_equal (1, 2); // error
    }

https://godbolt.org/z/fv3EeG7jx

It's more limited than full blown "constexpr parameters", mostly in that
it can't affect the return type, and there's no way to discriminate
based on "constantness".

On 8/29/25 17:22, Brian Bi via Std-Proposals wrote:
>
>
> On Fri, Aug 29, 2025 at 9:29 AM Григорий Шуренков via Std-Proposals
> <std-proposals_at_[hidden] <mailto: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] <mailto: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] <mailto: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] <mailto:Std-
> Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-
> Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
>
> --
> /Brian Bi/
>