On Sun, Mar 17, 2013 at 12:15 PM, John Tyree <johnty...@gmail.com> wrote: >> >> I was thinking of something along the lines of >> >> cdef extern from ...: >> cpp_string to_string[T](T value) >> T my_func[T, S](T a, S b) >> ... >> >> It's more a question of how to implement it. >> >> - Robert > > Well this closely matches the syntax used for classes and won't require any > type > inference, since the user supplies the type at the call site (am I reading > that > correctly?) so I'm not sure what about it will be particularly challenging. > > If it's done this way the compiler could generate prototypes as necessary in a > preprocessing step, without inferring anything about the types until later > when > overloading is resolved. That feels kind of hacky to me, but I've never > written > a compiler with the size and scope of Cython, maybe it's not too bad. This is > essentially what the user has to do already, and it "works". > > The biggest complaint I have about this method is that without inference it > looks like it could lead to a *lot* of extra writing out of types. I'm > dreading > the thought of writing out nested template types when calling factory > functions > like those in the thrust library, which was what motivated this in the first > place.
I think we need something to constrain the argument types (e.g. as they relate to each other), as well as provide a return type. The "any" type seems to lead way to easily to incorrect code, as well as surprises, e.g. is the "object" type accepted? (FWIW, I was thinking of allowing inference, that'll actually be pretty easy once the rest is in place.) - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
