Self-borrowing data would allow erganomic generativity

generativity and branded types are patterns used by crates like ghost_cell to allow safe code to do things it otherwise could not.

however, they have a limitation: because GhostToken "borrows" GhostCell, the two must always be stored in separate types, making it nearly impossible for library authors to hide the complexity of their implementation behind a single struct.

2 Likes

There's a universal agreement that self-referential types would be useful. The problem is only in the fact that they make borrow checking much more complex, and work towards making this possible (by rewriting the borrow checker) is taking years.

4 Likes

yeah, i know. i'm just adding yet-another advantage to the pile, since it's one i doubt a lot of people have thought of.

I wasn’t aware that any existing work on the compiler was aimed at supporting self-reference (unless you count futures/coroutines, which are just a different execution strategy for code that’s borrow checked in the normal fashion). Do you have any links handy that would be further reading?

1 Like

It's Step 4 in this blog post.

5 Likes

Indeed, some forms of self-borrowing types basically subsume existential lifetimes, which in turn allows "returning a fresh lifetime from a function" rather than having to use the closure callback pattern.

I was aware of this, and probably mentioned it in some discussions, but I don't think it's been very widely discussed indeed. Not sure if there is a nice way we can document this somewhere where it won't be forgotten again for the next iteration of self-borrowing types.

1 Like