On Apr 26, 2009, at 9:04 AM, Dag Sverre Seljebotn wrote:

> Danilo Freitas wrote:
>>>> That's a fair summary. I am also for supporting only a subset of  
>>>> what
>>>> is possible--if one really needs crazy stuff like differently
>>>> implemented prefix/postfix decrements and -> vs (*). one can  
>>>> code in C
>>>> ++ or use clever macros. (Would we need to expose ++, a.k.a
>>>> "__next__" for STL iterators?)
>>> Yes, you need ++/-- for std::list<T>::iterator, which doesn't  
>>> accept any
>>> form of +=, but we can just compile += 1 and -= 1 to those  
>>> operators in
>>> general (also for plain ints for that matter), so it's not really a
>>> problem. (We are then requiring that += 1 would have the same  
>>> semantics,
>>> which I'm 100% fine with.) This holds for both my and your stance  
>>> BTW
>>> and is orthogonal.
>>>
>>
>> Could we define a function int() and dec() for that?
>>
>> like, inc(iterator), dec(iterator).
>
> Good idea! +1, if it is done in the "cython" namespace:
>
> from cython import inc, dec
>
> Other "magic" functions are already like in the cython namespace (it's
> not a real module).
>
> Note that for STL iterators we also need *it rather than [0], so add
> "deref" to that list. Or possibly we just add * to Cython?
>
> We could then also move on to define the next builtin for C++ classes,
> which would translate like this:
>
> obj = next(it)
>
> would become
>
> cython.inc(it)
> obj = cython.deref(it)

In general, I like this proposal, but I do see some drawbacks when  
one extends beyond inc/dec. One problem is what would the return type  
of cython.decref be? I would rather see them as methods attached to  
objects (which is what they really are) than top-level functions.  
(cython.inc/dec could always return "void" (even thought they don't)  
and no function overloading needs to go on here).

I could see supporting unary * as a native Cython operator (though  
one would still want to be able to specify its type when operated on  
a class overloading it).

- Robert

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to