λ式におけるプレースホルダの最大のインデックスによって、結果の関数オブジェクトの引数の数が決定される。 しかし、これは単なる最少の引数の数であって、関数オブジェクトは任意の数の引数を取ることが可能である。(これらは不要なものであり、無視される。) 二つの bind 式と次の呼出しを考えてみる。

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 のレビューの推薦に従って、厳密な引数のチェックは却下された。