Last chance to fix std::nontype

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.

There is now a proposal [P2781R8] on track for C++29 which adds a std::constant_wrapper helper type, and this could be a plausible replacement for std::nontype. Considering that, do we even need std::nontype? Furthermore, 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".

In short, we now have to decide for C++26 whether std::nontype should be renamed (and if so, what to), whether it should be merged with std::constant_wrapper, or whether these constructor overloads should be delayed until C++29.

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 extremely 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.

2. Proposed solution

We can ditch std::nontype and obtain the functionality it provides in a different way. This would be very tempting because we don't have the dilemma of naming it right, making it redundant with std::constant_wrapper, having a weird workaround that becomes obsolete with constexpr function parameters, etc. Instead, we can get the same functionality using a tagged constructor.

The crucial observation in §1.2. Refresher on what std::nontype accomplishes is that the lambda we create for thunk-ptr cannot capture the constructor parameters. However, that is not actually necessary if we only need the type of the parameter, not its identity. The same approach is used for std::less, std::allocator, std::hash, etc. We don't need to hold an instance of these; we can just default-construct when needed. Specifically, the tagged constructor would function like:

2.1. Comparison with std::nontype

2.1.1. Note on free function ergonomics

While the construction from a regular function seems much more verbose with tagged constructors, [P3312R1] "Overload Set Types" could make this substantially more concise. Furthermore, it is common practice to create LIFT macros for this purpose, which would be used like:

Since most standard library functions aren't addressable anyway, the ergonomics of creating a std::function_ref directly from a free function may not be that significant. In fact, it could be argued that std::nontype encourages the user to write possibly-ill-formed code like std::nontype<std::sqrtf> by making it so frictionless.

2.2. Possible misuse of std::stateless

This possible bug can be easily caught by adding deleted constructors though:

An even better option would be to add Mandates specifications to the stateless_t constructors which require that the given callable is not a function pointer type. Although none of these fixes prevent the user from writing this mistake, it can be caught statically with ease, rather than actually resulting in undefined behavior.

2.3. Advantages compared to std::nontype

The proposed approach has several advantages:

• Providing tag types within constructors is a more well-established design within the standard library.
• The naming issue for std::nontype is eliminated completely. While the tag also needs a good name, we don't need to worry about conflicting with std::constant_wrapper, which seems harder to solve.
• Potential user confusion over what the difference between std::nontype and std::constant_wrapper is, and why the language needs both is, is eliminated.
• The design wouldn't feel immediately obsolete and deprecation-worthy once/if we get constexpr function parameters ([P1045R1]). It is worth noting that std::stateless does not require structural types, so there may be niche use cases where it could be used and std::nontype couldn't.

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. 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. However, as demonstrated in §1.2. Refresher on what std::nontype accomplishes, this helper type 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.

Author position: The functionality provided by std::nontype is a crucial part of std::function_ref, not a nice-to-have feature that can be ripped out. std::function_ref without these constructors would be akin to using containers without move semantics.

3.2. 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 not seen any seen any activity from the author since 2019. As nice as a core language solution would be, standard library features cannot be built on on hopes, dreams, and unimplemented hypotheticals. Even if constexpr function parameters were eventually implemented, it may be possible to integrate them into the existing set of constructors and to deprecate std::nontype.

Author position: Overall, there is little reason to treat constexpr function parameters as a prerequisite; we don't need to wait.

3.3. Replacing std::nontype with std::constant_wrapper

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

Major concerns have been raised over the fact that std::constant_wrapper is substantially more complex than std::nontype:

• std::constant_wrapper has an operator() already. If we have, say, std::cw<&f> made from some int f(), calling this wrapper would give us a std::constant_wrapper convertible to int. This means that it could also be passed into the constructor of a std::function_ref<int()> taking some callable type F&&.
• std::constant_wrapper also has a user-defined conversion function which returns the constant it wraps. If it wraps a function pointer (and this is a desired use case for std::nontype), this would also make the std::function_ref constructor taking F* (i.e. the function pointer constructor) a candidate. However, that candidate would always lose in overload resolution, so this is not a major concern.
• std::constant_wrapper would only treated specially by std::function_ref, but due to the behavior described in the previous bullets, it could also be passed into other "function wrappers" like std::move_only_function. This could easily confuse users who may expect that std::function_ref is a general mechanism for wrapping functions passed to such "function wrappers".

However, even with these major concerns, it would not be impossible to use std::constant_wrapper for this. The F&& and F* constructors should be losing in overload resolution anyway. Even if they didn't, the overload set could be modified to resolve ambiguity.

Author position: Considering the call operator and user-defined conversion functions of std::function_wrapper, the type is not a good fit for std::function_ref construction.

3.4. Exposing the BoundEntityType

Remember the example in §1.2. Refresher on what std::nontype accomplishes. Our end goal is to enable more possible constructions of std::function_ref. Technically, this could be done by ripping the implementation open and exposing its details:

However, this means that the user directly interacts with BoundEntityType, and this is a detail which may vary from implementation to implementation. For implementations that support conversion between function pointers and void*, BoundEntityType could simply be cv void*, but this may also be a union, it may be multiple pointers large, etc.

Author position: Exposing the BoundEntityType to the user seems like a bad idea, and it would encourage writing code that is inadvertently not portable.

3.5. Renaming std::nontype

Perhaps the most simple solution is to simply rename std::nontype. However, no good candidate with high consensus has been presented yet, and many options would be awfully similar to std::constant_wrapper, creating confusion:

• std::constant seems almost like a "more official" alternative to std::constant_wrapper, when this type is extremely limited on scope.
• std::ctp, std::cta, std::ct and other abbreviations derived from "constant template argument/parameter" feel out-of-place in the standard library, and cannibalize std::cw, the variable template for std::constant_wrapper.
• std::const_arg, std::constant_arg, std::constexpr_arg and other such names describe the purpose of the type well, but are still reminiscent of std::constant_wrapper.

Author position: Renaming std::nontype is not trivial, and it's unlikely that any solution will make everyone happy. Of all the options, std::constant_arg seems like the least bad candidate.

3.6. Conclusion

Every alternative seems bad in its own way, but §3.5. Renaming std::nontype seems least intrusive, and is definitely something that we could do for C++26.

In §5. Wording, both the wording for §2. Proposed solution and for §3.5. Renaming std::nontype is presented.

4. Implementation experience

§2. Proposed solution has been implemented at [GitHub]. This was done by forking the existing reference implementation of [P0792R14].

No issues whatsoever were encountered in the process; either solution provides the same functionality for the most part, although std::nontype does provide more direct support for function pointers and member pointers.

5. Wording

The following changes are relative to [N5008].

5.1. Option A — Replacing std::nontype with a std::stateless tag

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

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

In its place, insert the following declaration:

Change [func.wrap.ref.class], as follows:

Change [func.wrap.ref.ctor] as follows:

In [func.wrap.ref.deduct], delete the following deduction guides:

5.2. Option B — Renaming std::nontype to std::constant_arg

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

In [utility.syn], modify the header synopsis as follows:

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

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

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

6. References