How to write a GhostCell data structure exposing non-GhostCell interface?

[oxalica]

Consider we implemented a double-linked-list with GhostCell, and it's type definition would contains 'brand, and almost all it's method would take a GhostToken argument. Then if we want to expose it to end-user, with a std-like interface. It should be like LinkedList<T>, not LinkedList<'brand, T>. We should somehow create a wrapper storing both the structure and its GhostToken. So in every method, we use &mut or & to borrow the token of "the whole linked list", and access or mutate the content. But it seems to be not easy. We simply cannot "save" a lifetime. How can we hide GhostCell as an implementation detail for data structures?

[matthieu-m]

I have no idea.

Early on I explored the idea, and played around with a variety of solutions, but ultimately I gave up.

My idea was to use 'static as an erased lifetime, and then reparameterize with a local lifetime to performance operations, but I could never quite get it to work while still ensuring safety, and of course it breaks any operation mixing lists (splicing or splitting).

In the end, I am not sure it is possible to use GhostCell "internally": the user may have to buy into it.

---

One alternative I did think about was automated translation.

That is, since the code was proven correct (borrowing wise) with GhostCell, have a translation step that take the LinkedList and erases any trace of GhostCell and GhostToken, replacing them with unsafe code.

If the translation is manual, it's error-prone, however a vetted automated translation seems potentially possible.

[dewert99]

I've been exploring the idea of using 'static as an erased lifetime myself, and I came up with something that seems reasonable to me: dewert99/erased_brand. Is there any unsoundness with this idea you can find that I missed?