Bloomberg paper detector: online. Alisdair Meredith papers authored: approaching countably infinite. Carry on.

The paper buries the lede:

Library implementers must have this functionality internally, but it is not exposed to users.

This undersells the situation. When C++20 shipped class-type NTTPs, every stdlib implementation immediately needed to check structural-ness to implement their own mandates. The way they all did it: undocumented compiler intrinsics. Check libstdc++, libc++, MSVC STL sources — they all have equivalent private machinery. It has been sitting there for five years, unexposed, because there was no standard way to describe the predicate to users.

This paper is standardizing what compiler vendors already had to implement. The question is not "should we add this" — it is "why did this take until the NB comment phase of C++26 to write up."

Structural type check in C++20: squint at the error message and figure out which member broke it. Structural type check in C++26: is_structural_v<T>. Progress.

Section 3.1.1, Example 1:

template<typename V>
requires is_structural_v<decltype(V)>
struct const_wrapper { static constexpr auto value = V; };

This does not compile. V is a type parameter. decltype(V) is ill-formed — you cannot call decltype on a type. This should be template<auto V>. The intent is clearly a non-type template parameter constrained to structural types, but the example uses typename throughout the motivating section. Did these get built before submission?

Section 4 states:

The authors' preliminary thinking is that type traits and metafunctions should implement the abstract library API specification independently.

I understand the argument — different observable side effects (template instantiations vs. reflection queries). But this creates a correctness surface. Two independent implementations of the same predicate can drift. There is no enforcement mechanism. If is_structural_v<T> and is_structural_type(^^T) give different answers on an edge case, which one is authoritative? The answer "both are normatively specified against [temp.param] so they agree" is satisfying in theory and fragile in practice.

Rust solved const generic eligibility in 1.51. Types usable as const generic parameters implement PartialEq. Much simpler than C++, which needs this whole recursive "are all members public and non-mutable and also structural" walk.

Genuine question from someone who does not follow reflection closely: why can't you approximate this with a SFINAE probe? Something like trying to use T as an NTTP and seeing if substitution succeeds? Is the issue that structural-type violations are hard errors rather than substitution failures?

The most interesting thing in this paper is buried in Section 3.3:

The implementation could be improved if metafunctions such as "is this a literal type", "is this a lambda closure type", or "is this function constexpr" were available.

std::is_literal_type<T> was deprecated in C++17 and removed in C++20 on the grounds that it was too broad to be useful. Now, six years later, we need the reflection equivalent to implement is_structural_type correctly. The committee removed a building block, then built something that depends on the building block. This is not the first time and will not be the last.

The subtitle "US NB comment 49" is doing a lot of work in that title. This is a proposal responding to a National Body comment on a Committee Draft that is itself the output of a process that began with earlier papers. Somewhere there is a comment that generated a paper that cites a paper that addresses a comment that will generate another paper. The process is a fixed point.