<div dir="ltr">I actually just realized another nagging issue with C++/Cython: member typedefs are not supported:<div><br></div><div>cdef vector[T]:</div><div>      ctypedef size_t size_type</div><div><br></div><div>These "scoped" typedefs are very widely-used.  We can live without it, and we have been, but while we're making a list.. :)</div><div><br></div><div>--Kevin<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 20, 2016 at 11:15 PM Robert Bradshaw <<a href="mailto:robertwb@gmail.com">robertwb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 19, 2016 at 9:34 AM, Kevin Thornton <<a href="mailto:krthornt@uci.edu" target="_blank">krthornt@uci.edu</a>> wrote:<br>
> Hi Robert,<br>
><br>
> Related to this point, I think there are three important features that<br>
> Cython would benefit from, as far as C++11 and newer are concerned.  In<br>
> order of what I'm guessing to be increased complexity are:<br>
><br>
> 1. Non-type template parameters.<br>
<br>
This is actually probably the hardest :). There is a PR that's stalled<br>
out, probably needs some attention by both the author and us; it'd be<br>
great to get this in.<br>
<br>
> 2. "rvalue" references for standalone functions and class member functions:<br>
><br>
>     void foo[T]( T && t )<br>
<br>
>From a callers perspective, one can just declare an extern foo as<br>
foo(T) in Cython, it doesn't care if the actual call is made by value<br>
or by reference--the calling code is exactly the same.<br>
<br>
Actually implementing it for Cython-defined functions (as the callee)<br>
would require additional support, but would probably be pretty easy<br>
(implement a new type, with parsing, which generally behaves the same<br>
as a reference or value from Python's perspective--the actual heavy<br>
lifting happens in the C compiler).<br>
<br>
Want to file an issue on github for this?<br>
<br>
> 3. Variadic templates (member and non-member).  More generally, "parameter<br>
> packs":<br>
><br>
>     <a href="http://en.cppreference.com/w/cpp/language/parameter_pack" rel="noreferrer" target="_blank">http://en.cppreference.com/w/cpp/language/parameter_pack</a><br>
<br>
This'd be interesting (especially as to how it relates to changing the<br>
arity of functions for concrete instantiations). There's also a<br>
question of syntax. Maybe<br>
<br>
    void foo[A, int N, ... Types](A a, Types t):<br>
        ...<br>
<br>
It'd likely require #1, e.g. to be able to declare things like<br>
tuple_element::type such that std::tuple.get<N> would be correctly<br>
typed. Unfortunately seems declaring the (somewhat intuitive) API of<br>
std::tuple requires being able to declare a fair amount of its<br>
implementation.<br>
<br>
Still likely feasible though, and I think the notion of variadic<br>
templates is natural enough in a Python setting (which has had<br>
heterogeneously typed tuples since its inception, though of course not<br>
statically typed).<br>
<br>
> #2 is important for efficiency reasons--it isn't just a convenience feature.<br>
> Without it, Cython cannot support all the member function of std::vector,<br>
> etc.  The implication is that some expensive operations, like moving a big<br>
> object into a vector, require extra copies in Cython while a C++ program<br>
> would just move the object into the new location.<br>
<br>
It's interesting to call this an essential feature, given that C++<br>
itself didn't have it until recently :). Not that it can't be a big<br>
win, and libraries will more and more probably be designed assuming<br>
it.<br>
<br>
> #3 seems like the hardest, but would enable std::tuple, std::bind, and other<br>
> handy things to be used in a .pyx file.<br>
><br>
> Support for "auto" would be nice, but perhaps unrealistic.<br>
<br>
Just leave the cdef out and you basically get auto, i.e.<br>
<br>
    my_var = expr<br>
<br>
gives my_var the type of expr. If multiple assignments are made to<br>
my_var, it attempts to find a suitable union type that can hold all<br>
assignments. The one exception is for integers, where it infers the<br>
type to be object iff my_var is used in arithmetic expressions (that<br>
it can't deduce would not overflow with the finite-sized C integer<br>
type).<br>
<br>
> I know that PRs have been submitted, and since stalled out, on a couple of<br>
> these features.  I've tried to look at the Cython parser myself, but I'm not<br>
> able to follow it, sadly.<br>
><br>
> Thanks for all your hard work,<br>
><br>
> Kevin<br>
><br>
> On Fri, Aug 19, 2016 at 2:39 AM Robert Bradshaw <<a href="mailto:robertwb@gmail.com" target="_blank">robertwb@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> Though, as you discovered, there are some basic things like non-type<br>
>> template arguments that we would like to have. If there are other<br>
>> specific C++ constructs that are commonly used but impossible to<br>
>> express in Cython it'd be useful to know.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> cython-devel mailing list<br>
>> <a href="mailto:cython-devel@python.org" target="_blank">cython-devel@python.org</a><br>
>> <a href="https://mail.python.org/mailman/listinfo/cython-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/cython-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> cython-devel mailing list<br>
> <a href="mailto:cython-devel@python.org" target="_blank">cython-devel@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/cython-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/cython-devel</a><br>
><br>
_______________________________________________<br>
cython-devel mailing list<br>
<a href="mailto:cython-devel@python.org" target="_blank">cython-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/cython-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/cython-devel</a><br>
</blockquote></div></div></div>