On Sat, Aug 20, 2016 at 11:15 PM Robert Bradshaw <rober...@gmail.com> wrote:
> 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? > 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 <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 >
_______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
