Sorry, accidentally pushed Send too early on my other reply. On 20/11/2015 04:58, Domagoj Šarić wrote:
Actually, due to that new dark corner of the language (still somewhat dark to me too) called 'reference collapsing rules', that won't make much of a difference: even if you capture/bind an rvalue to a && it is no longer an rvalue (my 'non formal' understanding) and && member function overloads can only be called on rvalues...
Yes, within the function that gets called the && reference parameter is
an lvalue, not an rvalue, since it has a name. But all it takes to make
it an rvalue again is a call to std::move.
And this does not seem like unreasonable behaviour in itself, if that
only occurs once (perhaps to construct the result_or_error within the
function).
Even this is illegal (and really verbose) using your current rules:
typedef fallible_result