You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bananas are created from BananaTrees and their lifetime must not exceed the lifetime of their tree. banana_calories expects the passed banana to be alive, and transform_banana creates a banana from another one, preserving the lifetime information.
The lifetimes should cause the following function to be rejected by the compiler, because the result of transform_banana has lifetime bound to the lifetime of tree, which is tied to the enclosing block. leaked_banana and the following call to banana_calories should then be invalid.
fn main() {
let leaked_banana = {
let tree = BananaTree { ... };
let banana = create_banana(&tree);
transform_banana(banana)
};
println!("{}", banana_calories(leaked_banana));
}
If the bananas and functions are defined like this:
The lifetime bound 'a in Banana<'a> is used in the field calories, forcing the borrow checks and making the invalid use shown above fail with appropriate error message (tree does not live long enough):
fn main() {
let leaked_banana = {
let tree = BananaTree { calories: 105 };
let banana = create_banana(&tree);
transform_banana(banana)
};
println!("{}", banana_calories(leaked_banana));
}
Then the lifetime bound on Banana<'a> is not used in the member fields at all, but it still should be tied to the lifetime of the BananaTree passed to create_banana and it should limit the use of the created banana. It doesn't work like that, though, because the following function compiles:
fn main() {
let leaked_banana = {
let tree = BananaTree;
let banana = create_banana(&tree);
transform_banana(banana)
};
println!("{}", banana_calories(leaked_banana));
}
The lifetime of banana from create_banana is clearly not tied to lifetime of tree, because the compiler allows us to use the banana when its mother tree went out of scope.
This is in fact safe, because Banana didn't contain any reference to the BananaTree. The point is that I would like to use Rust's lifetimes in a C library bindings, where the Banana values live as long as their respective BananaTrees (as a matter of fact, the library is LLVM, banana trees are modules/functions and bananas are values).
The text was updated successfully, but these errors were encountered:
This has come up before though I'm not sure if there's another issue open for it. The case when this last came up was dealing with symbols from a dynamically loaded extension. It would be useful for, as @honzasp says, exposing lifetime information from external libraries.
Hi,
if a struct is bound by a lifetime which is not used in the body of the struct, this bound seems to be excluded from typechecking.
Consider following functions (not valid Rust, because the function and struct bodies are omitted):
Banana
s are created fromBananaTree
s and their lifetime must not exceed the lifetime of their tree.banana_calories
expects the passed banana to be alive, andtransform_banana
creates a banana from another one, preserving the lifetime information.The lifetimes should cause the following function to be rejected by the compiler, because the result of
transform_banana
has lifetime bound to the lifetime oftree
, which is tied to the enclosing block.leaked_banana
and the following call tobanana_calories
should then be invalid.If the bananas and functions are defined like this:
The lifetime bound
'a
inBanana<'a>
is used in the fieldcalories
, forcing the borrow checks and making the invalid use shown above fail with appropriate error message (tree
does not live long enough):On the other hand, if the implementation is like:
Then the lifetime bound on
Banana<'a>
is not used in the member fields at all, but it still should be tied to the lifetime of theBananaTree
passed tocreate_banana
and it should limit the use of the created banana. It doesn't work like that, though, because the following function compiles:The lifetime of banana from
create_banana
is clearly not tied to lifetime oftree
, because the compiler allows us to use the banana when its mother tree went out of scope.This is in fact safe, because
Banana
didn't contain any reference to theBananaTree
. The point is that I would like to use Rust's lifetimes in a C library bindings, where theBanana
values live as long as their respectiveBananaTree
s (as a matter of fact, the library is LLVM, banana trees are modules/functions and bananas are values).The text was updated successfully, but these errors were encountered: