Currently,
Given that the standard generally doesn't make move functions conditionally deleted, I tried to submit an LWG issue to constrain the move assignment operator of expected<cv void, E>. Edit: this is now LWG-4025.
It seems that the existence of deleted overloads can affect overload resolution in some corner cases, e.g. when someone uses a class derived from expected with using expected::operator=;. On the other hand, we can properly constrain copy functions since C++20, so it's doubtful whether expected should have deleted overloads.
Currently,
expectedhas all deleted overloads specified in the standard, including the inconsistent deleted overload of move assignment operator.expectedseems to have all but the inconsistent one (the defaulted overloads are sometimes deleted).expectedlacks deleted overloads (including those of copy constructors). My recent PR<expected>: Make copy/move assignment operators ofexpectedpropagate triviality #4271 doesn't change this.Given that the standard generally doesn't make move functions conditionally deleted, I tried to submit an LWG issue to constrain the move assignment operator of
expected<cv void, E>. Edit: this is now LWG-4025.It seems that the existence of deleted overloads can affect overload resolution in some corner cases, e.g. when someone uses a class derived from
expectedwithusing expected::operator=;. On the other hand, we can properly constrain copy functions since C++20, so it's doubtful whetherexpectedshould have deleted overloads.