HN Reader

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.

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

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.

These “weird expressions” probably get used code golf.

Why assigning a variable to a function that returns nothing is not a compilation error?

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?

they exist because whole language built to treat expressions as firstclass citizens : blocks, ifs, matches, even macros as expressions that return values. so once you internalize that, all these weirdo one liners are artifacts. just artifact of a system where expressions compose infinitely. the syntax tree runs deeper than most people's habbits allow. you hit that depth and brain says this is wrong but compiler's allowing.

Related: https://dtolnay.github.io/rust-quiz

Rust programs that give unintuitive outputs or compile errors.

Bruh, I started learning Rust yesterday. Why do you do this to me. Now I don't know anything I studied.

Honestly I'm surprised how not weird these are. Way less WTFy than Javascript, PHP, C or C++.

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)

I don't understand the one with dont(). Why does i.get() end up false at the end? Shouldn't it be true after having been set by dont()?

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...

yeah this is good, but now add lifetime annotations to have fun.

Great, now this stuff gets fed into LLM trainings and we'll see them in the next-gen model outputs.

Seriously though, I love "abusing" programming languages in unexpected ways. My favorite so far is: https://evuez.net/posts/cursed-elixir.html. Reading this made me realize Elixir is literally macros all the way down, and it's a Lisp!

I am sort of amused, a memory safe language deploys this sort of juggling

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

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.

I've absolutely seen some /cursed/ rust one liners.

if you extend it to the most cursed ~6 lines of code, you really can obfuscate what you're doing in a way that's fiendishly hard to debug.

this is why I like Go

With yesterdays release let chains got released. Really needed feature but can sometimes look pretty cursed: https://blog.rust-lang.org/2025/06/26/Rust-1.88.0/#let-chain...

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?

There's a fun RustConf talk on this topic from a few years ago. https://youtu.be/tNVDjMxCz-c

Once I tried how many `{{{...}}}` I needed to make javac crash. It wasn’t that many.