Lambda Rücksendung selbst: ist das legal?

Das Programm ist schlecht ausgebildet (die klappern richtig ist) pro [dcl.spec.auto]/9:

Wenn Sie den Namen einer Entität mit einem undeduced Platzhalter-Typ erscheint in einem Ausdruck, das Programm ist schlecht ausgebildet. Einmal nicht verworfen return-Anweisung in einer Funktion, jedoch, ist der Rückgabetyp, die sich aus dieser Erklärung verwendet werden können, in den rest der Funktion, auch in anderen return-Anweisungen.

Grundsätzlich der Abzug von der Rückgabetyp der innere lambda-Ausdruck richtet sich auf sich selbst (die Person benannt wird hier der Aufruf-operator) - also musst du explizit einen Rückgabetyp. In diesem besonderen Fall, das ist unmöglich, denn Sie müssen den Typ der innere lambda-aber können es nicht benennen. Aber es gibt andere Fälle, wo versucht zu zwingen, rekursive Lambda-Ausdrücke wie diese, das kann funktionieren.

Sogar ohne,, Sie haben eine dangling reference.

Ich möchte einige mehr, nach einer Diskussion mit jemandem viel klüger, (D. H. T. C.) Es gibt einen wichtigen Unterschied zwischen dem original-code (leicht reduziert) und die vorgeschlagene neue version (ebenfalls reduziert):

auto f1 = [&](auto& self) {
  return [&](auto) { return self(self); } /* #1 */ ; /* #2 */
};
f1(f1)(0);

auto f2 = [&](auto& self, auto) {
  return [&](auto p) { return self(self,p); };
};
f2(f2, 0);

Dass der innere Ausdruck self(self) ist nicht abhängig f1, aber self(self, p) hängt für f2. Wenn Ausdrücke sind nicht abhängig, Sie können verwendet werden,... eifrig ([temp.res]/8, z.B. wie static_assert(false) ist ein harter Fehler, unabhängig davon, ob die Vorlage es findet sich in instanziiert wird oder nicht).

Für f1 compiler (wie, sagen wir, clang) können versuchen, Sie zu instanziieren dieser eifrig. Sie kennen die abgeleiteten Typ von der äußeren lambda-sobald Sie, dass ; am Punkt #2 oben (es ist der innere lambda-Typ), aber wir versuchen, es zu benutzen früher (denke es ist wie bei Punkt #1) - wir versuchen, es zu benutzen, während wir noch analysieren der innere lambda-Ausdruck, bevor wir wissen, was Ihr Typ eigentlich ist. Das läuft in Konflikt mit der dcl.spec.auto/9.

Jedoch für f2 wir können nicht versuchen, zu instanziieren gespannt, weil es abhängig ist. Wir können nur instanziieren am point-of-use, durch die wir alles wissen.

Um wirklich so etwas wie dies tun, müssen Sie eine y-combinator. Die Umsetzung vom Papier:

template<class Fun>
class y_combinator_result {
    Fun fun_;
public:
    template<class T>
    explicit y_combinator_result(T &&fun): fun_(std::forward<T>(fun)) {}

    template<class ...Args>
    decltype(auto) operator()(Args &&...args) {
        return fun_(std::ref(*this), std::forward<Args>(args)...);
    }
};

template<class Fun>
decltype(auto) y_combinator(Fun &&fun) {
    return y_combinator_result<std::decay_t<Fun>>(std::forward<Fun>(fun));
}

Und was Sie wollen, ist:

auto it = y_combinator([&](auto self, auto b){
    std::cout << (a + b) << std::endl;
    return self;
});

TL;DR;

clang ist richtig.

Sieht es aus wie der Abschnitt der Norm darstellt, macht diese schlecht ausgebildet ist [dcl.spec.auto]p9:

Wenn Sie den Namen einer Entität mit einem undeduced Platzhalter-Typ erscheint in einem Ausdruck, der Programm ist
schlecht ausgebildet. Einmal nicht verworfen return-Anweisung in einer Funktion, jedoch, ist der Rückgabetyp
abgeleitet aus dieser Anweisung kann verwendet werden, in der rest der Funktion, auch in anderen return-Anweisungen.
[ Beispiel:

auto n = n; //error, n’s initializer refers to n
auto f();
void g() { &f; } //error, f’s return type is unknown

auto sum(int i) {
  if (i == 1)
    return i; //sum’s return type is int
  else
    return sum(i-1)+i; //OK, sum’s return type has been deduced
}

—end-Beispiel ]

Ursprünglichen Arbeit durch

Wenn wir uns den Vorschlag Ein Vorschlag zum Hinzufügen von Y Combinator, um die Standard-Bibliothek es bietet eine funktionierende Lösung:

template<class Fun>
class y_combinator_result {
    Fun fun_;
public:
    template<class T>
    explicit y_combinator_result(T &&fun): fun_(std::forward<T>(fun)) {}

    template<class ...Args>
    decltype(auto) operator()(Args &&...args) {
        return fun_(std::ref(*this), std::forward<Args>(args)...);
    }
};

template<class Fun>
decltype(auto) y_combinator(Fun &&fun) {
    return y_combinator_result<std::decay_t<Fun>>(std::forward<Fun>(fun));
}

und es explizit sagt, dein Beispiel ist nicht möglich:

C++11/14 lambdas nicht ermutigen Rekursion: es gibt keine Möglichkeit zum verweisen auf das lambda-Objekt aus dem Körper des lambda-Funktion.

und es verweist auf ein Koreferat in der Richard Smith spielt auf den Fehler, der Klang ist geben Sie:

Ich denke, dies wäre besser als ein first-class language feature. Ich lief die Zeit für die pre-Kona treffen, aber ich wollte schreiben, ein Papier zu ermöglichen, was eine lambda-einen Namen (eingeschränkt auf seinen eigenen Körper):

auto x = []fib(int a) { return a > 1 ? fib(a - 1) + fib(a - 2) : a; };

Hier, 'fib' das äquivalent der lambda *diese (mit einigen lästigen Besondere Regeln, damit diese arbeiten trotz der lambda-closure-Typ unvollständig sein).

Barry wies mich auf das follow-up Vorschlag Rekursive Lambda-Ausdrücke, die erklärt, warum dies nicht möglich ist, und arbeitet rund um die dcl.spec.auto#9 Einschränkung und zeigt auch Methoden dies zu erreichen ist heute ohne it:

Lambda-Ausdrücke sind ein nützliches Instrument für die lokale code-refactoring. Jedoch, das wir manchmal verwenden möchten, die lambda in sich selbst, entweder zu gestatten, direkte Rekursion, oder die Schließung, um registriert werden, als eine Fortsetzung. Dies ist überraschend schwierig, gut zu erreichen in der aktuelle C++.

Beispiel:

  void read(Socket sock, OutputBuffer buff) {
  sock.readsome([&] (Data data) {
  buff.append(data);
  sock.readsome(/*current lambda*/);
}).get();

}

Eine Natürliche Versuch, auf ein lambda von sich selbst ist, um es zu speichern in einer Variablen und erfassen, dass die variable per Referenz:

 auto on_read = [&] (Data data) {
  buff.append(data);
  sock.readsome(on_read);
};

Dies ist jedoch nicht möglich, da eine semantische zirkularität: der Typ des auto-variable nicht ableiten, bis nach dem lambda-Ausdruck verarbeitet wird, was bedeutet, dass der lambda-Ausdruck kann keinen Verweis auf die variable.

Anderen natürlichen Ansatz ist die Verwendung eines std::function:

 std::function on_read = [&] (Data data) {
  buff.append(data);
  sock.readsome(on_read);
};

Dieser Ansatz kompiliert, aber in der Regel stellt eine Abstraktion Strafe: das std::function kann entstehen, eine Speicher-Allokation und die Anrufung der lambda erfordert in der Regel einen indirekten Aufruf.

Für eine null-overhead-Lösung, oft gibt es keinen besseren Ansatz als die Definition einer lokalen Klasse Typ explizit.

Gut, dein code funktioniert nicht. Das bedeutet aber:

template<class F>
struct ycombinator {
  F f;
  template<class...Args>
  auto operator()(Args&&...args){
    return f(f, std::forward<Args>(args)...);
  }
};
template<class F>
ycombinator(F) -> ycombinator<F>;

Test-code:

ycombinator bob = {[x=0](auto&& self)mutable{
  std::cout << ++x << "\n";
  ycombinator ret = {self};
  return ret;
}};

bob()()(); //prints 1 2 3

Ihrem code sowohl UB und schlecht gebildet ist keine Diagnose erforderlich. Das ist lustig; aber beide können behoben werden, unabhängig.

Erste, der UB:

auto it = [&](auto self) { //outer
  return [&](auto b) { //inner
    std::cout << (a + b) << std::endl;
    return self(self);
  };
};
it(it)(4)(5)(6);

dies ist UB, weil äußere dauert self von Wert, dann ist innere fängt self Verweis, dann geht es zurück nach outer beendet. So segfaulting ist definitiv ok.

Fix:

[&](auto self) {
  return [self,&a](auto b) {
    std::cout << (a + b) << std::endl;
    return self(self);
  };
};

Dem code bleibt, ist schlecht gebildet. Um dies zu sehen, können wir erweitern den lambdas:

struct __outer_lambda__ {
  template<class T>
  auto operator()(T self) const {
    struct __inner_lambda__ {
      template<class B>
      auto operator()(B b) const {
        std::cout << (a + b) << std::endl;
        return self(self);
      }
      int& a;
      T self;
    };
    return __inner_lambda__{a, self};
  }
  int& a;
};
__outer_lambda__ it{a};
it(it);

diese instanziiert __outer_lambda__::operator()<__outer_lambda__>:

  template<>
  auto __outer_lambda__::operator()(__outer_lambda__ self) const {
    struct __inner_lambda__ {
      template<class B>
      auto operator()(B b) const {
        std::cout << (a + b) << std::endl;
        return self(self);
      }
      int& a;
      __outer_lambda__ self;
    };
    return __inner_lambda__{a, self};
  }
  int& a;
};

Damit wir Nächstes bestimmen Sie den return-Typ der __outer_lambda__::operator().

Gehen wir durch Sie Zeile für Zeile. Zunächst erstellen wir __inner_lambda__ Typ:

    struct __inner_lambda__ {
      template<class B>
      auto operator()(B b) const {
        std::cout << (a + b) << std::endl;
        return self(self);
      }
      int& a;
      __outer_lambda__ self;
    };

Nun, schauen Sie es -- seiner Rückkehr geben wird self(self) oder __outer_lambda__(__outer_lambda__ const&). Aber wir sind in der Mitte versuchen, Rückschlüsse auf die return-Typ von __outer_lambda__::operator()(__outer_lambda__).

Ihnen nicht erlaubt, das zu tun.

Während in der Tat der Rückgabetyp __outer_lambda__::operator()(__outer_lambda__) ist eigentlich nicht abhängig von der Rückgabetyp __inner_lambda__::operator()(int), C++ kümmert sich nicht, wenn die Aufzucht Rückgabewerte; es wird einfach überprüft den code Zeile für Zeile.

Sowie self(self) verwendet wird, bevor wir schließen es. Schlecht gebildet Programm.

Können wir patch dies durch ausblenden self(self) bis später:

template<class A, class B>
struct second_type_helper { using result=B; };

template<class A, class B>
using second_type = typename second_type_helper<A,B>::result;

int main(int argc, char* argv[]) {

  int a = 5;

  auto it = [&](auto self) {
      return [self,&a](auto b) {
        std::cout << (a + b) << std::endl;
        return self(second_type<decltype(b), decltype(self)&>(self) );
      };
  };
  it(it)(4)(6)(42)(77)(999);
}

und jetzt ist der code korrekt und kompiliert. Aber ich denke, das ist ein bisschen hack, benutzen Sie einfach die ycombinator.