если оно называется так же, как какая-нибудь другая структура: https://godbolt.org/z/sGcaf7nh4
Точнее, видит вместо него структуру, а не поле.
Кажется, он видит field< и начинает думать, что сейчас начнётся шаблон. А тут как раз тип. Но нешаблонный.
Ну вообще судя по ошибке такое чувство, что он ломается на этапе парсинга, ещё до семантического анализа Мне казалось, что [&] не захватывает поля класса и надо было писать явно this, разве нет?
Да ладно? Если убрать struct field {}, то все трое прекрасно захватывают поле. Небось даже this на самом деле, а не поле. Ну или если явно внутри написать (this->field < field), то тоже всё хорошо.
gcc и clang, lookup должен находить foo::field а не ::field
Обновление к посту двухлетней давности: не баг Visual Studio, а legacy lambda processor is on by default. Можно включить стандартное поведение: https://developercommunity.visualstudio.com/t/Visual-C-treats-name-of-a-lambda-captu/10378158? https://learn.microsoft.com/en-us/cpp/build/reference/zc-lambda?view=msvc-170 Оказывается, там довольно много опций вида "веди себя по-стандарту, а не как сделали в первый раз", не все включены по умолчанию.
Ответ стоило бы дополнить флагом /permissive-, который отключает все расширения. Флаги более свежих стандартов, рекомендованные в ответе, неявно его активируют. Лично я избегаю билдов msvc без этого флага, если нет намеренья полагаться на расширения.
Вроде как раз конкретно эту /permissive- не отключает: > The /permissive- option doesn't enable /Zc:lambda.
Обсуждают сегодня