fn evil_lincoln() { let _evil = println!("lincoln"); }

To understand what evil_lincoln is doing, you have to understand very old Rust. Here's the commit that introduced it: https://github.com/rust-lang/rust/commit/664b0ad3fcead4fe4d2...

    fn evil_lincoln() {
        let evil <- log "lincoln";
    }

It doesn't say explicitly why this is "weird", but given some other comments in the file,

    // FIXME: Doesn't compile
    //let _x = log true == (ret 0);

  if (i+=1) != (i+=1)

That '!' type seemed weird in the first few examples but starts to make sense later on.

It's essentially a "pseudo type" for everything that is syntactically an expression, but will never return anything, because evaluating it causes the entire statement to be canceled.

Is that correct?

    fn funny(){
        fn f(_x: ()){}
        f(return);
    }

The reason you want return to be coercible to any type is so that you can write something like

    let x: i32 = if y {
        4
    } else {
        return; // type ! coerced into i32
    }

(Note this all works even with returning a value)

Most contextual keywords in other languages come from either:

1. Features that were added after the language was in wide use and can't add keywords without breaking existing code.

2. Features where the word is particularly useful elsewhere, so would be painful to reserve (like `get` and `set` in Dart).

But neither of those seem to apply to Rust. As far as I know, it's always had ML-style unions, and "union" doesn't seem to be a particularly useful identifier otherwise.

Why isn't `union` fully reserved?

Rust programs that give unintuitive outputs or compile errors.

It's a C++23 library suite and lint set that eliminates:

- UB in all but the most contrived cases (I think I can get it to zero with a modest clang patch set) - bounds errors (see below) - bans all naked pointers and most references of any kind (NVRO and elision are mandated since 17, and on modern hardware like `znver5` you're usually pessimizing with e.g. `const foo_t& foo`) - and has no `usafe` keyword to fall back on, that's enforced at the conceptual module level by having things declare they are unsafe in their entirety via `extern "C"`

This stuff is really unlocked by C++23:

``` template<typename T> concept SafeIndexable = requires(T& t, const T& ct, size_t idx) { { t.at(idx) } -> std::same_as<typename T::reference>; { ct.at(idx) } -> std::same_as<typename T::const_reference>; // Banned: t[idx] };

// Wrapper that forces .at() usage template<SafeIndexable Container> class Safe { Container c; public: // Forward everything except operator[] template<typename... Args> Safe(Args&&... args) : c(std::forward<Args>(args)...) {}

    // Evil genius move: operator[] calls .at()
    auto operator[](size_t idx) -> decltype(auto) {
        return c.at(idx);  // Throws on bounds violation!
    }
    
    auto operator[](size_t idx) const -> decltype(auto) {
        return c.at(idx);
    }
    
    // Forward other operations
    auto begin() { return c.begin(); }
    auto end() { return c.end(); }
    // ... etc

// Usage: Safe<std::vector<int>> vec{1, 2, 3}; vec[10]; // Throws std::out_of_range instead of UB! ```

    fn main() {
      println!(r#"{:X?}{}"#,
        __=(|&__@_:&'_ _,|->_{[(|(..,_,__,_,):(_,_,((),),)|__..__)(__)]})({&(!(({"\"__'\\\\\
        \'";(||{('\"');()})();}>=*&())|(|__|__||__|__)((()<())&(()>()))),&[..=..],({0__.%-//
        0.;(|_:[();0],|{})([[],[],][0]);},),)}),_={(|_0_:[_;0],_:&[()]|{;_0_})({{[0;0]}},&[[
        ]][(0..)][{..}][0],);""},);
    }

Here's my favourite on that theme, which I was missing from the list:

    return return return return return return return return return 1