Наивысший индекс заполнителя в лямбда-выражении определяет удобство полученного функционального объекта. Однако это лишь минимальная аритмия, так как объект функции может принимать произвольно много аргументов; не нужные отбрасываются. Рассмотрим два связанных выражения и их призывы ниже:

bind(g, _3, _3, _3)(x, y, z); 
bind(g, _1, _1, _1)(x, y, z); 

Эта первая строка отбрасывает аргументы<x>и<y>и делает призыв:

g(z, z, z) 

Вторая строка отбрасывает аргументы<y>и<z>и призывает:

g(x, x, x)

В более ранних версиях библиотеки последняя строка приводила к ошибке компиляции времени. Это в основном компромисс между безопасностью и гибкостью, и этот вопрос широко обсуждался во время обзорного периода библиотеки Boost. Основные моменты длястрогой вежливостипроверка состояла в том, что он может поймать ошибку программирования в более раннее время и что выражение лямбда, которое явно отбрасывает свои аргументы, легко написать:

(_3, bind(g, _1, _1, _1))(x, y, z);

Это лямбда-выражение имеет три аргумента. Левая аргументация оператора запятой ничего не делает, и по мере того, как запятая возвращает результат оценки правой аргументации, мы заканчиваем вызовом<g(x, x, x)>даже со строгой вежливостью.

Основными аргументами против строгой проверки порядочности было то, что необходимость отбрасывать аргументы является обычным явлением и поэтому должна быть простой, и что строгая проверка порядочности на самом деле не покупает гораздо больше безопасности, особенно потому, что она не симметрична. Например, если программист хотел написать выражение<_1 + _2>, но по ошибке написал<_1 + 2>, со строгой проверкой порядочности, компилятор заметил бы ошибку. Однако если бы вместо этого было ошибочное выражение<1 + _2>, ошибка осталась бы незамеченной. Кроме того, слабая проверка быстроты немного упрощает реализацию. В соответствии с рекомендацией обзора Boost была отменена строгая проверка на прочность.