On Fri, Aug 19, 2016 at 9:34 AM, Kevin Thornton <krtho...@uci.edu> wrote:
> Hi Robert,
>
> Related to this point, I think there are three important features that
> Cython would benefit from, as far as C++11 and newer are concerned.  In
> order of what I'm guessing to be increased complexity are:
>
> 1. Non-type template parameters.

This is actually probably the hardest :). There is a PR that's stalled
out, probably needs some attention by both the author and us; it'd be
great to get this in.

> 2. "rvalue" references for standalone functions and class member functions:
>
>     void foo[T]( T && t )

>From a callers perspective, one can just declare an extern foo as
foo(T) in Cython, it doesn't care if the actual call is made by value
or by reference--the calling code is exactly the same.

Actually implementing it for Cython-defined functions (as the callee)
would require additional support, but would probably be pretty easy
(implement a new type, with parsing, which generally behaves the same
as a reference or value from Python's perspective--the actual heavy
lifting happens in the C compiler).

Want to file an issue on github for this?

> 3. Variadic templates (member and non-member).  More generally, "parameter
> packs":
>
>     http://en.cppreference.com/w/cpp/language/parameter_pack

This'd be interesting (especially as to how it relates to changing the
arity of functions for concrete instantiations). There's also a
question of syntax. Maybe

    void foo[A, int N, ... Types](A a, Types t):
        ...

It'd likely require #1, e.g. to be able to declare things like
tuple_element::type such that std::tuple.get<N> would be correctly
typed. Unfortunately seems declaring the (somewhat intuitive) API of
std::tuple requires being able to declare a fair amount of its
implementation.

Still likely feasible though, and I think the notion of variadic
templates is natural enough in a Python setting (which has had
heterogeneously typed tuples since its inception, though of course not
statically typed).

> #2 is important for efficiency reasons--it isn't just a convenience feature.
> Without it, Cython cannot support all the member function of std::vector,
> etc.  The implication is that some expensive operations, like moving a big
> object into a vector, require extra copies in Cython while a C++ program
> would just move the object into the new location.

It's interesting to call this an essential feature, given that C++
itself didn't have it until recently :). Not that it can't be a big
win, and libraries will more and more probably be designed assuming
it.

> #3 seems like the hardest, but would enable std::tuple, std::bind, and other
> handy things to be used in a .pyx file.
>
> Support for "auto" would be nice, but perhaps unrealistic.

Just leave the cdef out and you basically get auto, i.e.

    my_var = expr

gives my_var the type of expr. If multiple assignments are made to
my_var, it attempts to find a suitable union type that can hold all
assignments. The one exception is for integers, where it infers the
type to be object iff my_var is used in arithmetic expressions (that
it can't deduce would not overflow with the finite-sized C integer
type).

> I know that PRs have been submitted, and since stalled out, on a couple of
> these features.  I've tried to look at the Cython parser myself, but I'm not
> able to follow it, sadly.
>
> Thanks for all your hard work,
>
> Kevin
>
> On Fri, Aug 19, 2016 at 2:39 AM Robert Bradshaw <rober...@gmail.com> wrote:
>>
>>
>> Though, as you discovered, there are some basic things like non-type
>> template arguments that we would like to have. If there are other
>> specific C++ constructs that are commonly used but impossible to
>> express in Cython it'd be useful to know.
>>
>>
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel@python.org
>> https://mail.python.org/mailman/listinfo/cython-devel
>
>
> _______________________________________________
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Reply via email to