-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
avoid copies when returning by value #828
Labels
leads question
A question for the leads team
Comments
This comment was marked as outdated.
This comment was marked as outdated.
github-actions
bot
added
the
inactive
Issues and PRs which have been inactive for at least 90 days.
label
Dec 14, 2021
zygoloid
added
leads question
A question for the leads team
and removed
inactive
Issues and PRs which have been inactive for at least 90 days.
labels
Dec 14, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Instead of guaranteeing that a copy happens when returning by value, could we give a weaker guarantee that there is no lifetime issue, but that we may or may not make a copy?
What I'm thinking is: we could say that a function that returns by value may return a reference to anything that it knows lives at least as long as any of its parameters (including
me
). Then at the call site, we can check whether the returned value outlives any of the function parameters and make a copy if so. Then:I suppose we can avoid making a copy even in the second case in
H
by lifetime-extending the"hello"
temporary. I'm not sure that's a good idea; it might be too unpredictable.One problem with this is that the function return is creating an immutable view, and we need the callee to know how long it's promising that returned value will remain immutable for. I suppose this is nothing new; this is analogous to a classic C issue:
... where this either works or fails depending on whether
v[i]
produces a reference to an existing object (eg,v
isvector<string>
) or ends up bindings
to a temporary (eg,v
isvector<const char*>
). We might want some simple syntax to force a copy and end a chain of immutable views. (You could usevar
for that, but that also implies mutability, which might be undesirable.)There's also a calling convention complexity issue with this kind of approach: if
F
can either return a handle to some existing object or copy to some caller-provided storage, then the caller always needs to provide the storage and may need to perform a branch to tell whether it should provide a copy. That seems like something we could handle but I'm not sure whether it'll be worthwhile unless we get to avoid a lot of copies.Originally posted by @zygoloid in #821 (comment)
The text was updated successfully, but these errors were encountered: