Robert Bradshaw wrote: > As for the C++ project, it doesn't yet satisfy all C++ needs, but it > still makes wrapping C++ a lot nicer. A bit of cleanup is needed > before merging into main (e.g. we should verify we are in C++ > compiling mode before allowing C++ features). The holdup is operator > syntax--currently __add__, etc. are used, but if we support > references (which are not yet implemented, but should be pretty easy, > at least getting enough for external declarations) we can support C++ > operator+ style declarations. (This is especially relevant for how > the [] operator is handled.) I think this decision needs to be > settled before we push anything out, as I don't want to push the one > then deprecate it a month later.
Not that there's any hurry, but I'm curious: Do you have a plan for how the decision is going to be made? I guess it might be CEPable, once somebody has time for a CEP. Or a Skypecon or something. The way I see it is that the options are A: One try to keep current Cython semantics as far as possible. __add__. B: Really just let C++ into Cython entirely. operator++, and: - cdef int x = 3; func(x) # can change x - ++x # since it is different from += 1 in C++ - *x # Since it is different from x[0] in C++ - and so on I am, much to my own surprise, starting to lean towards B, much because one could then see C++ auto-wrapped and usable right away. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
