On Thu, Dec 05, 2013 at 09:27:03AM -0800, Patrick Walton wrote:
> This is great stuff, thanks. Have you given thought to how the
> rooting API would work? That's one of the last major pieces to making
> the Servo DOM type- and memory-safe.
Just to summarize what you and I talked about on IRC for the record:
Last time we talked about this on IRC, it was clear that current Rust
could not express the invariants we need to make this safe nor indeed
even to conviently implement the mechanism used by C++ today . As I
recall we came up with two mechanisms:
- some way to extract the return pointer, so that a constructor function
knows the address where the return value will be ultimately stored;
- a way to prevent values from being moved.
The former is an easy hack. The latter is a type system extension that
requires a bit of careful thought. The basic idea is to have the
borrow checker consider the value "pre-borrowed", since it already
prohibits moves from borrowed values. As I call our "rough sketch" of
a plan was to say that a function could use the special lifetime `'return`
in its return value:
struct Root<'a> { ... }
fn root() -> Root<'return> { ... }
For the callee (`root()`), the `'return` lifetime can be used like
other lifetime parameters. For the caller, though, `'return` has
special semantics. Precisely what those semantics are is up for debate
but here is a simple (though limiting) strawman: the function which
employs `'return` must be stored into a local variable, and `'return`
is bound to the enclosing block's lifetime. The variable is considered
immobile by the borrow check. (This same mechanism could be useful for
arenas.)
I am not especially happy with these two changes. They feel hokey and
special purpose. I guess the best sol'n depends on the degree of static
safety we want. Without something like the `'return` lifetime, I'm not
sure how we can guarantee that `Root` values follow a stack discipline
-- and maybe we don't want to, because it does remove some flexibility
(e.g., roots in data structures that transitively are tied to the
stack and hence do follow a stack discipline).
I was considering the idea of out-pointers a la Go. It would avoid the
hokey "get the return slot" thing and also add power to users by
putting DPS under their control. But it has complicated interactions
with generic functions (I can go into detail on that in a later mail),
and moreover it doesn't address the problem of forcing data to live on
stack or at least follow a stack discipline.
Niko
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
