Rename std::nontype,
and make it broadly useful

Contents

1. Introduction

[P2472R3] proposed additional overloads for the std::function_ref constructor which utilize a helper type std::nontype. This paper was merged into [P0792R14], which was plenary-approved at Varna 2023 for C++26.

The naming choice std::nontype makes very little sense following [P2841R1], which introduced concept and variable template parameters. Since those are not types either, what the standard used to call "non-type template parameter" has been renamed to "constant template parameter".

Furthermore, the std::constant_wrapper from [P2781R9] was accepted into C++26, and it seems like a good replacement for std::nontype at first glance. At Sofia 2025, the choice to rename std::nontype to std::constant_arg instead of replacing it with std::constant_wrapper achieved consensus, by the narrowest of margins (see P3740 minutes):

ACTION: Get feedback on the decision from standard library implementers.

POLL: Forward “P3740R1: Last chance to fix std::nontype” selecting Option A (change from nontype to constant_wrapper, also add overloads to other function wrappers (std::function)) to LWG for C++26 (if possible)

SF	F	N	A	SA
0	4	0	7	8

Outcome: No consensus for change

POLL: Forward “P3740R1: Last chance to fix std::nontype” selecting Option A (change from nontype to constant_wrapper, DO NOT add overloads to other function wrappers (std::function)) to LWG for C++26 (if possible)

SF	F	N	A	SA
6	7	2	6	0

Outcome: Weak consensus in favor

POLL: Forward “P3740R1: Last chance to fix std::nontype” selecting Option B (rename “std::nontype” to “std::constant_arg”) to LWG for C++26 (if possible)

SF	F	N	A	SA
7	9	2	2	1

Outcome: Consensus in favor

POLL: Forward “P3740R1: Last chance to fix std::nontype” selecting Option A (change from nontype to constant_wrapper, DO NOT add overloads to other function wrappers (std::function)) instead of Option B (rename `std::nontype` to `std::constant_arg`) to LWG for C++26 (if possible)

SF	F	N	A	SA
9	4	2	4	4

Outcome: No consensus for change

However, LWG had no time to review this extremely last-minute change, so it did not make it into C++26.

1.1. Why did we need a new std::nontype type?

An obvious question may be why the existing std::integral_constant cannot be used instead. This has multiple reasons:

• std::integral_constant<class T, T v> requires specifying the type separately.
• std::integral_constant has a lengthy name.
• std::integral_constant has a call operator which returns v, which produces friction with the other constructors.

1.2. Refresher on what std::nontype accomplishes

std::nontype is used only within constructors of std::function_ref:

Intuitively, std::function_ref is the C++ counterpart to the C idiom of passing void* and a function pointer which that void* is fed into, as seen in qsort. It is common practice to provide a null pointer to qsort and thus rely on a "capture-less" comparison.

With std::nontype, std::function_ref can support such use "capture-less" uses:

Crucially, it would be impossible to create a std::function_ref from a function directly without this helper. At best, we could store function pointer within bound-entity and call that function pointer from within bound-entity. This would introduce entirely unnecessary overhead.

Besides overhead, we need std::nontype constructors to make a std::function_ref which has the functionality provided by a lambda, but does not reference any specific lambda. This is crucial for being able to store std::function_ref somewhere long-term without paying attention to the lifetime of the callable type it has been initialized with.

2. Proposed solution

We propose to rename std::nontype_t and std::nontype to std::fn_t and std::fn. Such a rename is well within the scope of an NB comment, so it can be applied to C++26. Furthermore, we make the type more broadly useful for C++29 by

• making std::fn_t convertible to function pointers, and
• giving it a call operator, which makes it usable in function wrappers other than std::function_ref (with the same effect), as well as algorithms.

Expressed in code, this would look as follows:

Among other reasons, keeping std::nontype instead of using std::constant_wrapper in its place was controversial because there was not enough motivation to keep both. This is mainly because std::nontype provides no distinct functionality; it is effectively std::constant_wrapper without all of the extra operator overloads. What we propose addresses this problem.

2.1. Impact on std::function_ref

std::function_ref would handle std::fn exactly the same as std::nontype, whether it has this C++29 functionality or not. No C++26 code would be broken by adding those new members later. That is because there are special constructors for std::function_ref taking std::nontype, and these always win in overload resolution, whether std::nontype has a call operator or other members, or not.

Furthermore, std::function_ref needs to special-case std::nontype to provide the (nontype_t<f>, U*) and (nontype_t<f>, U&&) constructors. That is because only std::nontype provides the guarantee that its address is irrelevant to operator(), and that it is empty. Thanks to that guarantee, std::function_ref can use the bound-entity pointer to refer to some user-specified entity, or simply make it nullptr.

2.2. Making std::nontype useful for use in algorithms and function wrappers

A common recommendation when using standard library algorithms is to avoid the use of function pointers. That is because all invocations of of say, std::for_each with function pointers of the same type also result in identical instantiations.

Therefore, rather than making easily inlined direct calls to lambda operator()s, std::for_each</* ... */, void(*)(int)> makes indirect calls through a function pointer, and unless the algorithm is inlined and the function pointer is constant-folded, this may result in degraded performance.

The C++29 std::fn solves this problem by "elevating" the function pointer into the type system:

Furthermore, C++29 std::fn with a call operator could provide the same functionality to std::function, std::move_­only_function, and std::copyable_­function; it would simply be invocable like function pointers or lambdas. Even without any constructors added to the standard wording, implementations are free to apply small-object optimization, i.e. no allocations are necessary, which may improve quality of implementation further. This optimization is simply part of the "as-if rule".

A std::fn with a call operator just works with all function wrappers and algorithms, exactly as expected, and with the same semantics as it has in std::function_ref.

2.3. Making std::nontype useful for producing function pointers

Since the C++29 std::fn would be convertible to a function pointer, it could also be used for producing and converting function pointers. std::fn would be convertible to a function pointer type, possibly with conversions of parameters and the returned value being applied, not just if there is an "exact match" in signature.

Similarly, C++29 std::fn could be used to produce function pointers to arbitrary callable types such as lambdas, structs with a call operator, etc. All of this is feasible by creating a function "on the fly" within a conversion operator template. See §4.2. Possible implementation of std::fn for C++29 for specifics.

2.4. Naming

While using such a short and valuable name as std::fn would make little sense if std::nontype was simply being renamed with no further plans, we have big plans. std::fn would be the idiomatic way of lifting function pointers into the type system.

std::fn is inspired by the std::not_fn and std::mem_fn function templates. The future C++29 std::fn would have similar purpose to std::not_fn; it just wouldn't negate the result of an invocation.

However, such a short and valuable name is likely controversial. A plausible alternative is to use std::fw and std::function_wrapper, analogous to std::cw and std::constant_wrapper, or std::const_fn and std::const_fn_t, analogous to std::not_fn.

2.5. Change of header

Consider that std::fn is a more "functional name" than std::nontype, and that the goal is to follow up the rename with a call operator added in C++29, <functional> is a more appropriate header than <utility>.

Since std::function_ref is located in <functional> anyway, this change is largely inconsequential. It just means that users wouldn't be able to obtain std::fn through <utility> on its own, but we don't see strong motivation to do so.

2.6. Interoperability with third-party function_refs

It is worth noting that the proposed C++29 std::fn would work out-of-the-box with third-party function_ref implementations such as llvm::function_ref. Notably, std::fn would be a variable template, meaning objects of type std::fn_t have static storage duration. Therefore, binding an llvm::function_ref to std::fn does not risk creating a dangling reference.

However, it is still possible to produce a dangling reference to std::fn by deliberately copying it and creating a temporary object:

This is also one of the reasons why std::function_ref should special-case std::fn_t in its set of constructors. Other function wrappers need no special cases because they take ownership over the wrapped callable anyway.

3. Alternatives considered

Besides the proposed approach, there are other possible solutions. However, the author position is that every one of them is worse than what is proposed.

3.1. Using a std::stateless constructor tag instead

[P3740R0] proposed to replace std::nontype with a set of constructors that take a std::stateless constructor tag. This idea essentially died the moment LEWG saw the Tony Table which compares how users would pass function pointers to std::function_ref with std::stateless tags compared to std::nontype.

This alternative was not polled, but it was obvious during discussion that this option would not achieve consensus. See [P3740R0] for details.

3.2. Removing std::nontype with no replacement, revisiting for C++29

Since there is a lot of active work in this area, perhaps we could simply shove std::nontype into C++29 and deal with the problem later. As demonstrated in §1.2. Refresher on what std::nontype accomplishes, std::nontype covers crucial use cases such as

• constructing std::function_ref from a free function with no overhead, or
• constructing std::function_ref from an existing function pointer and void*, in the style of qsort.

This functionality is important to std::function_ref, and it has shipped in C++26 already. None of the authors see it as reasonable to rip this functionality out entirely for C++26.

3.3. Waiting for constexpr function parameters

std::integral_constant, std::constant_wrapper, and std::nontype are – to an extent – temporary hacks. If we were able to write

… then the workaround of std::nontype would be obsolete.

At Kona 2023, EWG showed enthusiasm for this option when discussing [P1045R1] "constexpr Function parameters".

Poll: P2781R3 “std::constexpr_v” and P1045R1 “constexpr function parameters” EWG would like to solve th eproblem solved by std::constexpr_v in the language, for example as proposed by P1045R1 or with “expression aliases”, rather than solving it in library. An implementation is desired. C++26 seems ambitious.

SF	F	N	A	SA
6	8	5	1	0

However, [P1045R1] has been abandoned by the original author, but picked up by a new author (proposal pending). Nonetheless, constexpr function parameters do not entirely obsolete our design, it is unclear if they will be in C++29, and the std::nontype functionality has already shipped in C++26. Therefore, it makes very little sense to wait for this feature.

3.4. Replacing std::nontype with std::constant_wrapper

The seemingly obvious solution is to use std::constant_wrapper from [P2781R9]. The option to use std::constant_­wrapper as a replacement for std::nontype was discussed during an LEWG telecon 2025-03-11.

In short, the problems stem from the fact that std::constant_wrapper is already invocable; it already has a call operator, whose semantics would be ignored by std::function_ref, in a way that is inconsistent with how std::constant_wrapper behaves anywhere else.

More details can be found in [P3740R1], as well as in [P3792R0] "Why constant_wrapper is not a usable replacement for nontype".

In any case, LEWG already decided (with paper-thin consensus) not to pursue this path.

4. Implementation experience

4.1. Simple rename for C++26

Renaming std::nontype requires no implementation experience because it is merely changing the name of a symbol; it obviously works. This is what we are proposing for C++26.

4.2. Possible implementation of std::fn for C++29

An implementation for illustration purposes of the full C++29 std::fn may look as follows:

Note that the wording strategy for std::fn_t in C++29 would leave its details largely unspecified, which would allow for not implementing operator() at all, and for making std::fn_t invocable via surrogate function call (implicit conversion to function pointer, then calling that pointer). See § Appendix — Follow-up wording for C++29

5. Wording

The following changes are relative to [N5008].

In [version.syn], update the feature-test macro:

In [utility.syn], delete the declarations of std::nontype and std::nontype_t:

In [functional.syn], change the synopsis as follows:

In [func.wrap.ref.class], replace every occurrence of nontype_t with fn_t:

In [func.wrap.ref.ctor], replace every occurrence of nontype_t with fn_t:

In [func.wrap.ref.deduct], replace every occurrence of nontype_t with fn_t:

6. References

Appendix — Follow-up wording for C++29

The following changes are relative to [N5008], with the changes in §5. Wording applied.

In [version.syn], create a feature-test macro:

In [functional.syn], change the declaration of fn and fn_t as follows:

Between [func.identity] and [func.not.fn], insert a new subclause: