Условно кажется рекурсивная лямбда без захвата должна уметь кастануться в указатель на рекурсивную функцию

Рекурсивная лямбда – довольно странная необходимость, но если уже что-то понадобилось, то вопрос за каким-то оверхедом вряд ли стоит

Ты по ссылке не сможешь захватить, не положив её в std::function

?

С какого стандарта такое?

С любого. auto l = [&l]{}; не соберётся.

Потоуммучто тут тип не выведен

Тоесть он рекурсивно зависим

Это не странная необходимость. Рекурсивный визитор для какой-нибудь древовидной структуры - навскидку

Так я о том же. Захват не поможет реализовать рекурсивную лямбду

Кажется, там либо ещё один иф, либо где-то совершенно неожиданно может сломаться совместимость, очень похоже, что большинство пунктов существуют только потому что "так исторически сложилось", ибо сейчас name lookup изнутри тела лямбды — не очень очевидная штука, на мой взгляд

то есть было бы очевиднее иметь доступ к внутренностям closure object?

Нам ведь для рекурсивного вызова не нужно захватывать сам объект лямбды, мы уже в теле closure type, и для него же гарантируется стандартом наличие operator(). Достаточно позволить вызывать его изнутри, при этом не нужно будет ни захватывать, ни обращаться к объекту лямбды по имени из лямбда-выражения, поэтому проблемы нет. Цена — лишнее условие в стандарте и не самый красивый синтаксис

Собственно, в моём примере это получилось и у GCC, и у MSVC просто потому что они предоставляют operator() внутри лямбда-выражения

Мы обсуждали текущие возможности стандарта, где для вызова лямбды внутри самой себя надо иметь в том или ином виде this

Думаю, что да, хотя я и прекрасно понимаю, что придётся разбираться с тем, чей this мы хотим видеть внутри выражения и тут без неочевидных решений тоже никак, кажется

то, что имеется сейчас, точно проще объяснять

Да грубо говоря можно впилить штуку типа mutable специально для этого

[]()скишками{}

Но ключевые слова добавлять неоч

При желании любой другой this можно передать явно