I guess its equivalent to Go code like this:

    value, err := stuff()
    if err != nil {
        panic(err)
    }

    int result = stuff();
    assert(result >= 0);

> What sort of "interacting with raw pointers" are you thinking of that's too inconvenient and ugly for your liking?

I have 2 complaints. First, I wish Rust had a -> operator or something like it. This sort of thing is horrible:

    (*(*(*ptr).foo).bar)

Here's an unsafe function which manages the internal state of a skip list:

https://github.com/josephg/jumprope-rs/blob/3981256e4e741d8b...

This code is insanely fragile. There are multiple pointers to different elements floating around. The only way I got miri to calm down was to dereference the node pointer constantly. Eg:

    *cursor.num_bytes -= (*node).str.len_bytes();
    let next = (*node).first_next().node;

As a general principle, unsafe rust should be as simple and easy to reason about as possible so we can spot security problems. But rust's syntax makes unsafe code very complex. I don't think this complexity is in any way necessary.

However surely the aliasing is actually a problem and so MIRI is annoyed because what you wrote might be wrong? If we hang on to (*node).first_next() but somehow node changes, we're no longer talking about the same thing, it's exactly the aliasing problem.

I'd have to (which I have not) examine in detail how your code works to offer an opinion beyond speculation, but I think my instinct is sympathy for the "Don't write aliases" approach.

Yes, requiring that nothing alias it’s much more conceptually elegant. But as I said, in practice it makes programming extremely treacherous. There are no warnings when you alias. No errors. 99% of the time you’ll get a working program with no bugs every time you build. You’re just - quietly - at the whim of llvm. Maybe it won’t compile correctly on some other architecture. Maybe a minor compiler bump, or different flags, will make your program totally broken. The only way to discover there’s even a potential problem is by running the code through MIRI.

I get why it’s like this but I think it’s a mistake. I think unsafe rust should be at least as expressive and pleasant to work with as C. Having quiet foot guns here seems antithetical to rust’s philosophy of safe ergonomic programming.

I guess you've "really missed" this feature or more likely you are considering only the case where our function signature says we return Result and so early returning Option won't compile.

Because the modern "try v2" operator is a trait, it is implemented for Option, Result, and ControlFlow plus Poll variations.

Historically its ancestor the try! macro was provided only for Result, but that's a very long time ago now.

Let me give you another example you've probably used without realising it, when you write password.contains("foo") in Rust. Why can you write "foo" there? Rust doesn't have overloading, and yet you can pass strings, characters, and functions including lambdas - how can this work? They all implement core::str::pattern::Pattern, an unstable trait used to deliver this functionality for all string matching.

In fact mechanically what's happening here for Try is that ? always worked for Option and Result, the "try v2" feature isn't about the syntax at all, it's about the behind the scenes implementation of that syntax. But that's not important, the syntax is promised and the final implementation will almost certainly be tryv2 or something very similar.