On Thursday, 10 July 2014 at 21:01:23 UTC, Timon Gehr wrote:
On 07/10/2014 10:10 PM, "Marc Schütz" <schue...@gmx.net>" wrote:
...
Instead of lifetime intersections with `&` (I believe Timon
proposed
that in the original thread)
I didn't. I suggested that _some_ suitable syntax might need to
be found. :)
Apologies, then :-)
But the point still stands - I don't think we need to introduce
"invented" lifetime names as Rust does, we can refer to existing
identifiers/symbols instead.
The root cause of the problem here is the call to `free()`.
(Proving the safety of code containing manual free requires
different machinery.)
I think that once manual memory management is involved, it's
impossible to make safety guarantees in the general case. But I
also believe that not all is lost: Much can be won when the
_implementers_ of libraries take special care (in our case by not
marking free() as scope), so that library _users_ cannot
accidentally run into these problems. And because the
trouble-makers can be clearly identified, there is even a simple
rule that covers probably 99% of the cases: "Don't make memory
deallocators take borrowed pointers."
The reason I'm not completely sure about it is that move
semantics can have the same effect as manual memory management:
It's possible to move a unique object into a lower scope, which
is then destroyed at the end of that scope. It's just much less
obvious...
