Weird Expressions in Rust

Posted by lukastyrychtr 6/27/2025

Weird Expressions in Rust(www.wakunguma.com)

195 points | 151 comments

steveklabnik 6/27/2025|

This post is missing my favorite one!

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

What's weird about this?

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";
    }

log was a keyword to print stuff to the screen. Hence the joke, https://en.wikipedia.org/wiki/Lincoln_Logs Now that log is the println! macro, the joke is lost.

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);

I am assuming that using the return value of log was buggy, and so this tested that you could save it in a variable. I don't remember the exact semantics of log, but if it's like println!, it returns (), which is useless, so binding it to a variable is something you'd never write in real code, so it's "weird" in that sense.

mbStavola 6/27/2025||

A dog entered a tavern and said: "I cannot see anything, I'll open this one!"

hansjorg 6/27/2025||

Tough crowd.

ibotty 6/27/2025|||

What's the joke exactly? English is not my native language.

jerf 6/27/2025||

https://www.basicfun.com/lincoln-logs/

This would be something the Boomer generation grew up with, and I think maybe the previous generation too. They're still around but they've certainly faded; they used to be Lego-level popular kids toys back then. They are named after President Lincoln, but only as a marketing tactic to use some of his reputation, there's no real connection.

I would imagine even some native English speakers are learning something with this post. I haven't seen them in a while.

drfuchs 6/27/2025|||

There’s a strong connection between President Lincoln and log cabins. He grew up in a series of log cabins, and this fact was widely known during his campaign.

dolmen 6/28/2025||||

We have a brand in France that is a bit older (1911) that also still makes wood toys.

https://www.jeujura.fr/

ranguna 6/27/2025||||

Yes, but why is it evil?

Analemma_ 6/27/2025||

I think that part is a reference to a Futurama episode where a holodeck malfunction materialized several villains, including "Evil Lincoln".

ranguna 6/28/2025||

Ah if that's the case, then that makes more sense. Thanks!

saghm 6/27/2025||||

I'm a late millennial, and I'd sometimes see them as a kid too. I'm not sure about more recent generations, but I think that they might have stuck around longer than you might think.

iforgotpassword 6/27/2025||

I saw some kids in a park a few years ago in Beijing playing with those. First time I saw them. Didn't know the name until now though. :)

bennettnate5 6/27/2025||||

> They were named after President Lincoln, but only as a marketing tactic

> there's no real connection

Funny--I always thought it was meant to be a pun on linkin', as in you're linkin' the logs together because they have those slots that fit precisely together on the ends.

saghm 6/27/2025||

I think it's both that and the popular tale of Lincoln having been born in a log cabin (which for some reason I thought I had heard wasn't actually true, but from looking into it now, it seems like a lot of sources say it is, so maybe I heard wrong?)

kelnos 6/28/2025||||

They were still pretty common when I was a kid in the early '80s. genX'ers and older millennials born in the US are likely to know about them, or perhaps even have had a set of them (I did).

Timwi 6/28/2025|||

> This would be something the Boomer generation grew up with

... in your country I assume. I've never heard of these, but from the looks of it, they look like an American version of Playmobil or Fisher Price.

rendaw 6/27/2025|||

What's the joke exactly? English is my native language.

steveklabnik 6/27/2025||

log "lincoln" is a reference to the toy "lincoln logs"

san1927 6/28/2025||

love this one thats a really underrrated fact

ramon156 6/27/2025||

Note that for Rust devs these are also weird syntaxes. I feel like some people assume that an experienced dev can read these, but it takes a while to get what's going on.

ChuckMcM 6/27/2025||

Kind of like obfuscated C code I suspect.

dathinab 6/27/2025||

yes, but less risky (and less power full) because you often very fast can conclude that "whatever it does it's safe, sound and doesn't affect unrelated code"

caim 6/27/2025||

And how would you conclude that "fast"?

You can have UB in "safe rust".

https://github.com/Speykious/cve-rs

You can even disable the Type check, trait check and borrow check in "safe rust"

And all of this is unsound.

https://users.rust-lang.org/t/i-finally-found-the-cheat-code...

jenadine 6/28/2025|||

Or you can have malicious code that is not unsafe. Does it mix sensible data with something that is being sent? Does it always accept "return break union" as a valid password? Things like that.

dathinab 6/28/2025|||

yes, but that is a different kind of unreadable code then in the blog

the blog focuses mainly on putting expresions into unusual positions and how some things have an implicite () type and some an implicite ! type etc.

either way if you see strange code you probably shouldn't copy/merge it without having a very good understanding of what it does

01HNNWZ0MV43FF 6/27/2025||

Yeah. I've been doing Rust for a few years and when I look at these I just see "Failed PR review, unreadable to humans"

lacker 6/27/2025||

I think there's a mistake in the explanation for "bathroom_stall". When describing the guard in this expression:

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

The post says, "The if statement is always going to be false because the right expression will always be one more than the left." But it's a not-equals. The if statement is always going to be false because in Rust "i += 1" doesn't return an integer value, it returns a (). So comparing any two += statements, they are always equal. Since the guard is a != comparison, the if statement is always false.

xg15 6/27/2025||

Rust noob here.

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?

NobodyNada 6/27/2025||

Yes, exactly -- it's called the Never type.

It's also useful in more places than return expressions -- for example, you can make a function return ! to indicate that it's a non-returning function, which is useful for expressing, say, an error handler that must crash the program; or a main loop that must never return. It also can help the compiler generate more compact code when a function is known to not return.

There's currently work in progress to allow you to specify ! as a type everywhere, not just as function returns. This is useful where some generic code expects a function to return a Result with an implementation-specified error type, since an infallible implementation can specify ! as the error type. Then, the type checker can allow the programmer to unwrap a Result<T, !> without checking for errors, and the optimizer can remove the error-checking branches from generic code: https://doc.rust-lang.org/std/primitive.never.html

This has taken a very long time to implement, because of some very subtle implications on type inference that made it difficult to stabilize without breaking compatibility -- but the 2024 edition finally figured out a way to make it possible.

int_19h 6/27/2025|||

Not necessarily the entire statement, just some outer expression.

Which might make more sense when you remember that the only statements in Rust are various declarations (`let`, `type`, `fn` etc) and macro invocations. Everything else is an "expression statement", including blocks and loops. Thus you can do stuff like:

    // Compute the first Fibbonaci number >10
    let n = {
        let mut x1 = 0;
        let mut x2 = 1;
        loop {
            let x = x1 + x2;
            if x > 10 { break x }
            x1 = x2;
            x2 = x;
        }
    };

Note that `break` never leaves the let-statement here - it just terminates the loop expression and forces it to yield a value (`break` without arguments yields (), and ditto for loops without break).

You can also break out of regular blocks if they are labelled and you use the labelled form of break:

   let x = 'label: { ... break 'label 42 ... }

This all can very easily lead to convoluted code if not used sparingly, but sometimes a mutating loop with mutable data encapsulated within and a break to yield it once the computation is complete is genuinely the most straightforward way to write something.

Analemma_ 6/27/2025||

Yes. If you look at steveklabnik's example with the match statement elsewhere in the comments, it makes sense that '!' is the "never" or "unreachable" type, not because the return expression isn't run, but because its value will never be assigned to a variable, since it causes an unconditional exit from the function.

arjvik 6/27/2025||

I figured out how return-as-a-value made sense only upon realizing that in the following code,

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

f() is never called because funny() returns before it gets called.

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
    }

And you pick the return value of ! because return never actually produces a value that is propagated on at runtime, it immediately exits the function.

(Note this all works even with returning a value)

munificent 6/27/2025||

Does anyone know why `union` isn't a reserved word in Rust?

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?

pitaj 6/27/2025||

It's a common operation on sets, so would make `HashSet::union` [1] and friends less obvious, for no real benefit.

[1] https://doc.rust-lang.org/stable/std/collections/struct.Hash...

steveklabnik 6/27/2025||

It's simply that Rust has higher standards for breaking changes than "probably not in wide use." In other words, that someone could have had `let union =`... somewhere was a reason to make it contextual.

https://rust-lang.github.io/rfcs/1444-union.html#contextual-...

munificent 6/28/2025||

Ooooooh, I see my confusion now.

My brain switched off and I got enums and unions confused. I was like, wait, hasn't Rust had them since day one? I was thinking of `enum`, not `union`. My bad.

steveklabnik 6/28/2025||

Ahhh yeah, no worries!

armchairhacker 6/27/2025||

Rust programs that give unintuitive outputs or compile errors.

benreesman 6/28/2025||

I'm actually working on a project I'm quite serious about but jokingly refer to as "Ergonomic Rust", which would make all of it a weird expression in Rust.

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! ```

matt_kantor 6/28/2025||

Many moons ago[1] I wrote this, which seems appropriate to share here:

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

[1]: https://www.reddit.com/r/rust/comments/8p013f/comment/e094qj...

kzrdude 6/27/2025|

Many of them are on the same theme - the theme is `return -> !`.

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

    return return return return return return return return return 1

wredcoll 6/27/2025|

Is there some meanining to the number of returns?

kzrdude 6/27/2025||

No, it's just nonsense. Same result with fewer or more returns..

More comments...