CEP 503 - Compile-time operator overloading

Status: Wanted
Implementation status: Not started
Comments: This is part of DagSverreSeljebotn's GSoC 2008 project proposal

What could one want to do with operator overloading in Cython?

The cases I can think of:

Simply declare that an operator is available C/C++ side so that one can "let" an operator on the type through. Declaring the type is important so that coercion can happen Cython-side.
Add a thin layer of syntax candy around C functions that does the operation.
Writing new types in Cython itself that supports operator overloading. I haven't checked whether this is already supported.
Do something more complicated Cython-side. For instance, to support negative indices, bounds checking, slices, variable number of arguments etc., quite complicated argument parsing is needed. This is the NumPy case -- first off, the number of arguments will vary, second off, the expression will contain lookups and divisions which are not cached/optimized by GCC on -O3 and thus optimization must happen Cython-side (see GCC experiment below).

In order to make things clearer, I propose that seperate mechanisms are needed for

letting through operators from C into Cython on the one hand (tackles 1), and
overriding an operator with a Cython expression on the other hand (tackles 2,3,4)

The former is about declaring the capabilities of the type C-side while the latter will be about declaring what Cython-code should be generated when hitting operators.

Syntax

The former case is not discussed here, see the C++ page. For the latter case, Python-like syntax is proposed:

cdef class Foo:
    cdef Foo __add__(self, Foo other):
        return add_foo(self, other)

add_foo might here be either a declared C function or more Cython code. On this level, any kind of fancy parameters for [] is supported, by writing the obvious Cython code to interpret the argument list (as a Python tuple structure).

Which operators?

The normal set of Python binary operators, getitem, setitem etc.

Also some Cython-specific operators are probably wanted for controlling coercion behaviour etc. (similar to C++ cast operators).

Return type of getitem? (slices etc.)

The return type of the getitem operator (the operator for []) is a problem because it is esentially used for both looking up an element in a collection and for getting slices, and the return type of the former will typically be different from the latter.

Some ways in which this can be solved (in order of increasing complexity):

Introduce a new operator, getslice, which by default calls getitem, and which can be overloaded with a different return type.
Allow overloading on method return type. Then getitem can be declared twice, once for each return type (and each would also assert the form of their parameters). See notes in the the overloading document for details.
Return object, and rely on inlining and optimization to automatically remove conversion back and forth.