гарантированное исключение копийguaranteed copy elision

До C++17 выражение вида return Widget(args); формально создавало временный объект, который затем move- или copy-конструировался в объект результата — компиляторы почти всегда пропускали этот шаг оптимизацией (copy elision), но именно как оптимизацию: move/copy-конструктор обязан был существовать и быть доступен, даже если реально не вызывался. C++17 переопределяет саму семантику prvalue (pure rvalue) — значение вида Widget(args) в контексте инициализации не является «временным объектом, который потом надо переместить», а напрямую описывает, как сконструировать объект результата. Никакого временного объекта не возникает — значит, конструктор перемещения/копирования не нужен вообще, ни для вызова, ни для самого факта существования.Before C++17, an expression like return Widget(args); formally created a temporary object which was then move- or copy-constructed into the result object — compilers almost always skipped this step as an optimization (copy elision), but strictly as an optimization: a move/copy constructor still had to exist and be accessible, even if it was never actually called. C++17 redefines the semantics of a prvalue (pure rvalue) itself — a value like Widget(args), in an initialization context, isn't "a temporary object that must later be moved" — it directly describes how to construct the result object. No temporary object is ever created, so a move/copy constructor isn't needed at all, neither for the call nor merely for existing.

class NoCopyNoMove {
public:
    NoCopyNoMove(int) {}
    NoCopyNoMove(const NoCopyNoMove&) = delete;
    NoCopyNoMove(NoCopyNoMove&&)      = delete;
};

NoCopyNoMove make() {
    return NoCopyNoMove(42);
    // C++14: ошибка компиляции — move-конструктор нужен// C++14: compile error — a move constructor is required
    // формально, даже если оптимизатор его не вызовет// formally, even though the optimizer would never call it
}

class NoCopyNoMove {
public:
    NoCopyNoMove(int) {}
    NoCopyNoMove(const NoCopyNoMove&) = delete;
    NoCopyNoMove(NoCopyNoMove&&)      = delete;
};

NoCopyNoMove make() {
    return NoCopyNoMove(42);
    // C++17: компилируется — Widget(42) это prvalue,// C++17: compiles — Widget(42) is a prvalue,
    // конструируется напрямую в объекте результата вызывающего// constructed directly into the caller's result object
}

Проблема была не в производительности (оптимизаторы и так почти всегда убирали копию) — проблема была в том, каким кодам это разрешено компилироваться:The problem wasn't performance (optimizers already elided the copy almost every time) — the problem was which code was even allowed to compile:

Ключевое разграничение — три разных случая, которые часто путают между собой:The key distinction is between three different cases that are frequently confused with each other:

// (1) return prvalue-выражения напрямую — ГАРАНТИРОВАНО C++17// (1) returning a prvalue expression directly — GUARANTEED in C++17
Widget make1() {
    return Widget(1, 2);  // prvalue — конструируется прямо в объекте результата вызывающего,// a prvalue — constructed straight into the caller's result object,
}                        // move-конструктор Widget не обязан существовать// Widget's move constructor doesn't need to exist

Widget w1 = Widget(3, 4);  // (3) copy elision при инициализации — тоже ГАРАНТИРОВАНО C++17// (3) copy elision on initialization — also GUARANTEED in C++17
                             // ровно один объект w1, никакого временного// exactly one object w1, no temporary involved

// (2) NRVO для именованной локальной переменной — НЕ гарантировано, всё ещё оптимизация// (2) NRVO for a named local variable — NOT guaranteed, still an optimization
Widget make2() {
    Widget w;             // именованный локальный объект// a named local object
    w.configure();
    return w;              // компилятор МОЖЕТ применить NRVO (обычно применяет),// the compiler MAY apply NRVO (usually does),
}                        // но формально это по-прежнему move — конструктор нужен// but formally this is still a move — the constructor is required

Разница между (1) и (2) — не косметическая. В (1) выражение Widget(1, 2) само по себе является prvalue: у него никогда не было отдельного адреса, отдельного от объекта результата, до которого его можно было бы «переместить» — компилятор просто обязан сконструировать объект результата, используя аргументы 1, 2. В (2) w — это полноценный именованный объект с собственным адресом на стеке функции; возврат w формально требует переноса его состояния в объект результата вызывающего, и стандарт лишь разрешает компилятору пропустить этот перенос (NRVO), не обязывая. Отсюда и правило: move-конструктор всё ещё должен существовать и быть доступным для (2), даже если реально не вызывается почти никогда.The difference between (1) and (2) isn't cosmetic. In (1), the expression Widget(1, 2) is itself a prvalue — it never had a separate address, distinct from the result object, from which it could be "moved" — the compiler is simply required to construct the result object using the arguments 1, 2. In (2), w is a full named object with its own address on the function's stack; returning w formally requires transferring its state into the caller's result object, and the standard merely permits the compiler to skip that transfer (NRVO), without requiring it. Hence the rule: the move constructor must still exist and be accessible for case (2), even though it's almost never actually invoked in practice.

• cppreference — Copy elision
• WG21 P0135 — Guaranteed copy elision through simplified value categories