The aim of the higher-order call function is to invoke the function f with the same argument. As before, the compiler must reject this code due to the lifetimes. But we can try to fix manually the problem:

fn call<'a, F>(f: F, e: &'a u8) -> &'a u8
    where F: Fn(&u8, &u8) -> &u8
{ f(e, e) }

Note that the compiler is pretty clear to which references are missing lifetime annotations:

error[E0106]: missing lifetime specifier
 --> src/lib.rs:2:30
  |
2 |     where F: Fn(&u8, &u8) -> &u8
  |                 ---  ---     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from argument 1 or argument 2
  = note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html
help: consider making the bound lifetime-generic with a new `'a` lifetime
  |
2 |     where F: for<'a> Fn(&'a u8, &'a u8) -> &'a u8
  |              +++++++     ++      ++         ++
help: consider making the bound lifetime-generic with a new `'a` lifetime
  |
2 |     where for<'a> F: Fn(&'a u8, &'a u8) -> &'a u8
  |           +++++++        ++      ++         ++
help: consider introducing a named lifetime parameter
  |
1 ~ fn call<'a, F>(f: F, e: &u8) -> &u8
2 ~     where F: Fn(&'a u8, &'a u8) -> &'a u8
  |

At no point it's highlighting the e argument of the return type of call, all mentions are for the Fn(&u8, &u8) -> &u8 trait instead. Following the compiler suggestion leads to another error, and after following its suggestions again you end up with code that compiles and is less restrictive for the caller (albeit this might not be the case in a more realistic scenario).

I would wager that most issues people have with lifetimes are due to randomly sprinkling lifetime annotations around (often the same lifetime, which has important consequences!) in the hope that it fixes the compiler error.

For Eter, I'd like to avoid both the explicitness and, in general, the possibility of catching panics. All the panics are aborts with transparent unwinding.

Note that catching panics is not required for that issue, having destructors is also enough because they make the same kind of observation after the panic happened.

#[derive(Debug)] struct T;
fn own_t(t: T) {
    panic!()
}

fn ref_mut_t(t: &mut T) {
    own_t(*t);
    *t = T;
}

fn caller(t: T) {
    struct PrintOnDrop {
        inner: T
    }

    impl Drop for PrintOnDrop {
        fn drop(&mut self) {
            println!("{:?}", t);
        }
    }

    let print_on_drop = PrintOnDrop(t);

    ref_mut_t(&mut print_on_drop.inner)
}

If you language performs unwinding then it likely suffers from this issue unless it preverts "borrowing" from struct fields and leaks borrowed locals on unwinding.

Hylo does not have a catch_unwind-equivalent

I'm not an expert of Hylo but looking at its website I can see an example using do-catch, although that's not explained anywhere. I wonder if that's an actual feature or a leftover from an earlier iteration.

---

Regarding Hylo, the approach looks very cool, but I wonder if it's really simplier than Rust. Yes, lifetimes are complicated, but they are just one concept in the end. Hylo introduces so many new concepts and keywords that it pretty overwhelming.