-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Mark templates users shouldn't specialize with no_specializations
attributes
#5536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
_NO_SPECIALIZATIONS
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
… it unconditional.
This marks the definition of coroutine_handle, and the declarations of generator, variant, and allocator_traits, to match their counterparts.
…at_context, which were missing.
…ts>` and `<xtr1common>`.
…ype traits I checked that everything in `<xtr1common>` is depicted by the Standard in `<type_traits>`.
Click to expand usage example:
#include <chrono>
#include <type_traits>
template <class T>
struct Kitty {};
namespace std {
namespace chrono {
template <class T>
struct is_clock<Kitty<T>> : true_type {};
} // namespace chrono
} // namespace std
int main() {
static_assert(std::chrono::is_clock<Kitty<int>>::value);
}
It was difficult to search the Standard but I didn't find any other occurrences of missed enforcement. Now all we have to do is remember to keep this current as we implement new features! (Oh yeah, and deal with any fallout in the internal builds and tests, which I will take care of.) |
Thanks to @MattStephanson for reminding me about Click to expand member class template example:
#include <mdspan>
#include <memory>
template <typename T>
struct Kitty {};
namespace std {
template <typename T>
struct layout_left::mapping<Kitty<T>> {};
template <typename T>
template <typename U>
struct allocator<T>::rebind<Kitty<U>> {};
} // namespace std
|
_NO_SPECIALIZATIONS
no_specializations
attributes
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Thanks for helping users write more conformant code! 😻 🪄 📈 |
This PR marks templates users shouldn't specialize with
[[msvc::no_specializations]]
or[[clang::no_specializations]]
, depending on the compiler.Resolves #5179.
All citations in this PR description are to WG21-N5014.
Class Templates
[namespace.std]/2 allows class template specializations by default. Exceptions:
initializer_list
compare_three_way_result
allocator_traits
coroutine_handle
is_execution_policy
basic_format_arg
basic_format_context
basic_format_parse_context
is_clock
generator
range_adaptor_closure
variant
tuple
unary_function
binary_function
Variable Templates
[namespace.std]/3 forbids variable template specializations by default.
format_kind
disable_sized_sentinel_for
enable_borrowed_range
disable_sized_range
enable_view
enable_nonlocking_formatter_optimization
e_v
log2e_v
log10e_v
pi_v
inv_pi_v
inv_sqrtpi_v
ln2_v
ln10_v
sqrt2_v
sqrt3_v
inv_sqrt3_v
egamma_v
phi_v
Type Traits
[meta.rqmts]/4 forbids specializing any template in
<type_traits>
by default.common_type
basic_common_reference
Function Templates
Specializing function templates is forbidden, but, following the decision made in #24, this PR doesn't touch any of them (except for
is_pointer_interconvertible_with_class
andis_corresponding_member
in<type_traits>
, as specializing those has always been forbidden).Notes
Relevant: llvm/llvm-project#118167 implemented this warning in libc++.