I of course agree with Dimi. Expressing non-esapability is essential, but the important use-cases can be covered without introducing the complexity of a named lifetime system. It isn't important to be able to express every possible use case without using an (encapsulated) unsafe construct. We saw from the beginning of Hylo's design process that we'd need something like Span to fill the role of Swift's Slice, and we designed the language to accommodate that use case without introducing named lifetimes. Named lifetimes have been shown by Rust to be difficult for users. I realize this design isn't exactly the same as Rust's, but it's similar enough.
I fear that Swift has lost an ethos of saying “no” to complexity that doesn't pull its weight and that this is an example.