[C++-sig] Automatic support for operator[] and operator()

[David Abrahams]

I started to write this:

--schnipp--
It would be great to support

   .def(self[int] = double())  // defines '__setitem__' method
   .def(self[int()] = double())  // defines '__getitem__' method
   .def(self(int(),double(),double()))
--schnapp--

But then I remembered that we need to provide a way for (and
encourage) people to supply bounds-checking code which will raise the
appropriate IndexError or KeyError exception for the [] operator.

And the function-call example is a bit unweildy. More on that later.

Maybe the way to go here is to supply an interface like:

    .def_getsetitem(&X::operator[], _2 < boost::lambda::bind(&X::size, _1))

Or, for those of us with broken compilers that don't support Boost.Lambda:

    .def_getsetitem(&X::operator[],
        boost::bind(std::less<std::size_t>(), _2, boost::bind(&X::size, _1)))

I'm not sure this is the best interface direction; I'm interested in
other ideas. The one part I think is valuable is the passing of a
function object to help with range detection. However, I note that
there's no way for the user to specify IndexError or KeyError here. So
maybe handcrafted __get/setitem__ methods are really best after all.

Regarding the function-call example, I don't think the above provides
significant benefit over the existing facilities for defining
"__call__". However, it did get me thinking: we don't need to specify
the return type in these operator expressions; maybe our
BOOST_PYTHON_[MEMBER]_FUNCTION_OVERLOADS() macros should take
advantage of the same techniques so that users don't have to supply
the return type of their overload set(s). I'm not sure there's much to
be gained here, but it's worth a thought.

-Dave
-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution