1. 15
  1.  

  2. 8

    Although the topic isn’t too novel, I’m submitting this since I thought people might be interested in the fact that Eli started blogging about Rust. I always found his blog posts to be well-written and insightful, and this one is no exception.

    1. 1

      Is Eli Bendersky someone of note?

      1. 4

        Probably not if you’d use Wikipedia’s definition of “notable”, but he’s a prolific blogger and (in my non-authoritative opinion) an excellent writer.

    2. 5

      Based on our previous discussions of ownership, it sounds like it can. So how can a reference in a child assume the same lifetime? It can’t.

      That’s very esoteric, and I don’t think I’ve ever used this in practice, but there’s a Rust feature that allows for that. Specifically, if everything you want to do with the value is to drop it, and the value doesn’t have a custom drop impl, the references inside the value are allowed to dangle. That’s safe because without custom drop no one will actually access those dangling references.

      So, for example, the following compiles:

      use std::cell::Cell;
      
      struct Node<'a> {
          data: i32,
          left: Option<Box<Node<'a>>>,
          right: Option<Box<Node<'a>>>,
          parent: Cell<Option<&'a Node<'a>>>,
      }
      
      impl<'a> Node<'a> {
          fn new(data: i32) -> Self {
              Self {
                  data,
                  left: None, right: None,
                  parent: Cell::new(None),
              }
          }
      }
      
      fn main() {
          let mut p = Node::new(2);
          p.left = Some(Box::new(Node::new(1)));
          p.right = Some(Box::new(Node::new(3)));
          p.left.as_ref().unwrap().parent.set(Some(&p));
          p.right.as_ref().unwrap().parent.set(Some(&p));
      }
      

      (the canonical post to read here is https://exyr.org/2018/rust-arenas-vs-dropck/)