From a6581eee89bcff3eb9e2e1d25d47da827a58aa81 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20K=C3=B6ppe?= Date: Mon, 8 Sep 2025 19:52:41 +0100 Subject: [PATCH] pytypes.h: constrain accessor::operator= templates so that they do not obscure special members (#5832) * pytypes.h: constrain accessor::operator= templates so that they do not match calls that should use the special member functions. Found by an experimental, new clang-tidy check. While we may not know the exact design decisions now, it seems unlikely that the special members were deliberately meant to not be selected (for otherwise they could have been defined differently to make this clear). Rather, it seems like an oversight that the operator templates win in overload resolution, and we should restore the intended resolution. * Use C++11-compatible facilities * Use C++11-compatible facilities * style: pre-commit fixes --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> --- include/pybind11/pytypes.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/pybind11/pytypes.h b/include/pybind11/pytypes.h index 9c60c94c0..cee4ab562 100644 --- a/include/pybind11/pytypes.h +++ b/include/pybind11/pytypes.h @@ -1039,11 +1039,11 @@ public: void operator=(const accessor &a) & { operator=(handle(a)); } template - void operator=(T &&value) && { + enable_if_t>::value> operator=(T &&value) && { Policy::set(obj, key, object_or_cast(std::forward(value))); } template - void operator=(T &&value) & { + enable_if_t>::value> operator=(T &&value) & { get_cache() = ensure_object(object_or_cast(std::forward(value))); }