-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Terminology for managing ownership #25
Comments
I wonder, even though there is already use of Steal, does there need to be a difference for non-refcounted data? Why not use Consume for both types of data? |
To me, “consume” sounds like it'll destroy the object, not just the reference to it. |
I dislike "steal" term, it's negative and I don't think that it's easy to get its meaning. I prefer "move" or "transfer". In python/cpython#111489 I propose to make |
I wrote python/cpython#112975 which adds fuctions:
I chose Maybe with a concrete PR, it may be easier to decide on the naming convention for functions which move/transfer reference ownership. The current implementation leaves the source array unchanged. |
FWIW I still prefer “steal”. So this is not settled. |
|
IMO, the proper term, which should be used in documentation, is transfer ownership. However, that's too long for an API name suffix. Using just |
Creating a PR doesn't imply that anything is settled. As I wrote, I proposed a PR to help to better see which name fits better. |
In terms of "ownership", Rust has many concepts and tools for that, and ownership is a key concept in Rust. In Rust, the action of transferring ownership is called "move": https://doc.rust-lang.org/rust-by-example/scope/move.html
C++11 introduced
|
Per capi-workgroup/problems#11, we need terms for managing ownership.
IMO, it would be useful to use similar terms both for references and to non-refcounted resources -- typically, allocated memory.
Arguments
By default, ownership of arguments is not transferred. After a call:
The caller must guarantee that the arguments stay valid for the duration of the call.
“Output” arguments (where the callee gets a
*result
pointer and fills it) follow rules for return values.We should use shorter, context-specific terms for transferring ownership (the non-default-behaviour):
PyObject*
or other refcounted/GCd data (i.e. other references might exist). Used for performance optimizations or ergonomics.PyObject*
), e.g. string builder finalization API would consume the scratch data and return a new objectPyObject*
toNULL
)I'm aware that Steal is pejorative; but IMO it's better than the alternative (Take, Give, Move)
Another useful exception is:
Return values
By default, ownership of the return value is transferred. After a call:
The opposite is:
Borrow: the caller must not decref/free the return value, but is responsible for ensuring that it is not accessed after its lifetime ends. Docs for the called function need to indicate what that lifetime is.
Static is, conceptually, borrowing from the interpreter itself.
The text was updated successfully, but these errors were encountered: