On Fri, Aug 19, 2016 at 9:34 AM, Kevin Thornton <krthornt@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?
Sure--will do.
> 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.
Also, libraries not designed assuming it can still take advantage of it in many contexts. For lots of objects, the move constructor can be implicitly created by the constructor.
Also, this would solve some quirks for Cython. Right now, std::unique_ptr is supported, but the object is non-copyable. One needs std::move in order to have this type be fully-functional.
> #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).
This is surprising to me. Would my_var be passable to a "cdef nogil" function? I'll have to give this a try--thanks for the tip!
> 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 <robertwb@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