Usunięto konstruktor - MSVC zgłasza błąd, Clang nie

Question

Rozważmy następujący kod:

class SILPassPipelinePlan final { 
public: 
    SILPassPipelinePlan() = default; 
    ~SILPassPipelinePlan() = default; 
    SILPassPipelinePlan(const SILPassPipelinePlan &) = default; 
    SILPassPipelinePlan(SILPassPipelinePlan &&) = delete; 

    SILPassPipelinePlan x() { 
    SILPassPipelinePlan P; 

    return P; 
    } 
}; 

int main() { 
    return 0; 
} 

MSVC zgłasza następujący błąd:

1>consoleapplication2.cpp(13): error C2280: 'SILPassPipelinePlan::SILPassPipelinePlan(SILPassPipelinePlan &&)': attempting to reference a deleted function

1>consoleapplication2.cpp(8): note: see declaration of 'SILPassPipelinePlan::SILPassPipelinePlan'

Clang i GCC nie.

Z punktu widzenia specyfikacji, który kompilator jest prawidłowy? Czy jest to błąd MSVC, czy błąd Clang?

MSVC pochodzi z najnowszej aktualizacji Visual Studio 2015 Update 3, Clang w wersji 3.9.0.

Answer 1

C++ 11 wprowadzono ukryte ruchy w niektórych scenariuszach — yours included:

In the following copy-initialization contexts, a move operation might be used instead of a copy operation:

• If the expression in a return statement ([stmt.return]) is a (possibly parenthesized) id-expression that names an object with automatic storage duration declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression, or

• […]

overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If the first overload resolution fails, […]

dzyń (. Realizacja tylko przyjmowanie, btw) albo błędnie "nie" obejmuje wybór usuniętych funkcji, lub stosuje [over.match.funcs]/8 zbyt leniwy. Zobacz błąd 31025.

Answer 2

Wszystkie wersje GCC na Wandbox odrzucają ten kod. Czy przez przypadek testujesz to na Macu i używając jego Clang-masquerading-as-GCC?

Nie ma to nic wspólnego z P0135. Clang jest po prostu biorąc nadmiernie liberalnej odczyt „nie” w tym, co jest obecnie [class.copy.elision]/3, który mówi, że w tej sytuacji

overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If the first overload resolution fails or was not performed, [...], overload resolution is performed again, considering the object as an lvalue.

To przeciążenie rozdzielczość nie powiedzie; to się uda i wybiera konstruktor ruchu, który ma zostać usunięty. To powinien być koniec sprawy.

Zostało to zgłoszone jako bug 31025.