<memory>: shared_ptr(nullptr_t, Deleter)'s constraint interacts badly with generic lambdas #503
Description
C:\Temp>type meow.cpp
#include <memory>
using namespace std;
int main() {
shared_ptr<int> sp{ new int(0), [](auto ptr) { delete ptr; } };
}
C:\Temp>cl /EHsc /nologo /W4 /std:c++latest meow.cpp
meow.cpp
meow.cpp(5): error C2541: 'delete': cannot delete objects that are not pointers
meow.cpp(5): note: see reference to function template instantiation 'auto main::<lambda_1>::operator ()<std::nullptr_t>(_T1) const' being compiled
with
[
_T1=std::nullptr_t
]
meow.cpp(5): note: see reference to variable template 'const bool conjunction_v<std::is_move_constructible<`main'::`2'::<lambda_1> >,std::_Can_call_function_object<`main'::`2'::<lambda_1> &,std::nullptr_t &,void> >' being compiled
This appeared after we implemented LWG-2875 "shared_ptr::shared_ptr(Y*, D, [...]) constructors should be constrained" in VS 2017 15.5.
Here, the user wants to construct a shared_ptr from a raw pointer and a custom deleter, and that constructor (also constrained by LWG-2875) works fine. However, the (nullptr_t, Deleter) constructor participates in overload resolution even though it's not desired (and int * ultimately isn't convertible to nullptr_t). LWG-2875's aggressive constraint asks whether deleter(nullptr) is valid. For a generic lambda, this attempts to instantiate the lambda's body, which fails unrecoverably (instead of SFINAE).
We should file an LWG issue for this. I believe this could be solved by templating on Nullptr and specifying that whether Nullptr is convertible to nullptr_t must be checked before deleter(nullptr) is checked.
It's possible that this could be solved in the Core Language by saying that the viability of non-templated argument conversions should be checked before running template argument deduction and substitution, but I have no idea how to phrase such Standardese or what kind of havoc it could wreak. (I vaguely recall this being discussed on the Committee's internal mailing list for Core, but I can't remember the exact thread.)
Originally reported as DevCom-371962 and Microsoft-internal VSO-722757.