> What is the problem (as @Araq stated in his first reply to this thread) is > that the logic to determine whether to "move" an owned paramater or to copy > it as a "dangling" is too ambiguous _when the destination doesn 't specify > that it is owned_ such that when the compiler uses the same rule as it uses > for proc parameters as to "last read/use of", it then incorrectly moves an > owned to a "dangling".
And this is what I already wrote. An `owned` gets passed to a `sink`. But the `sink` is not a `sink owned`. Now, suddenly: > What is the problem (as @Araq stated in his first reply to this thread) is > that the logic to determine whether to "move" an owned paramater or to copy > it as a "dangling" is too ambiguous when the destination doesn't specify that > it is owned such that when the compiler uses the same rule as it uses for > proc parameters as to "last read/use of", it then incorrectly moves an owned > to a "dangling". So , either you declare `sink owned`, or an `owned` can't be passed to a `sink`. This is the conclusion, because ambiguity has to be avoided. There is an alternative though. The alternative works with coercions. Let's call the coercion `f_owned`, then my description given above (with lifetimes, Rust-style) could be written as: `proc sinkprocUsing(dst: var f_owned Widget; src: sink f_owned Widget)` . The compiler then could infer that `dst` gets coerced to an `owned` , transferring ownership from `src`. The callee itself can either deallocate `src` and assign a new Widget to dst or assign src to dst (your example). > Applying the general rule of making dw automatically "lift" to be an owned on > such an assignment would seem to be overly complicated and confusing, B/D already have the "take" operator. Coercion does the same basically. They are a bit unclear though about the lifetimes of aliases of `src`. Do they follow now the lifetime of `src` or do they follow the lifetime of `dst`? With a strict runtime approach (the sad way) premature deallocation of `dst` would lead us to a runtime error. Better: lifetime of `dst` gets max(src,dst). Static analysis could tell us. > as in the case where the assignee were an element of a seq as in the Original > Post (OP) the compiler (and programmer) would have to deal with the case > where some seq elements are owned and others not - not something that should > have to be considered. An `owned` requires a seq[`owned`] to be placed in, of course.
