This is just a shorter synonym for __identity<T>::type.
Use it consistently throughout, where possible.
There is still some metaprogramming in <memory> and <variant>
where __identity is being used _without_ immediately calling
::type on it; but this is the unusual case, and it will become
even less usual as we start deliberately protecting certain types
against deduction (e.g. D97742).
(Btw, I've really looked at the instances in <memory> and I think they cannot trivially be adjusted to use __identity_t; it's using __dependent_type<__identity<T>, Dummy>::type and thus relying on the fact that __identity<T> is non-final even when T is final. I have not really looked at the instances in <variant>; I think it's using __identity<T> as an empty tag type for dispatch, similar to in_place_type_t<T>, but I'm not technically 100% sure.)
@ldionne wrote:
I agree, but when I started trying to do that, I immediately ran into existing implementation divergence; see https://godbolt.org/z/bxhn84 (libstdc++ rejects, libc++ and MSVC accept) and my tonight's LWG reflector thread "P1518 redux: CTAD deducing Allocator/Compare from random constructors". I definitely think the libc++/MSVC behavior is the "correct" behavior, so I'd want to preserve it, even if it means putting __identity_t on more ctor arguments than the paper standard currently mandates.
But now that's a feature-ish enough change that I'm gonna just land this "NFCI" commit as-is, and open a different PR if I decide it's worth doing anything else (which I still might, but it's no longer a slam-dunk).