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!
Rust does not claim to be particularly security-focused, only memory safe.
Also, this means that you'd consider any expression-based language to be inherently a security problem.
Rust is not written as a pure expression based language. And as we all know very well from the experience with C and JS, any unexpected and weird looking code has the potential to hide great harm. Allowing programmers to stray too much from expected idioms is dangerous.
It’s not purely expression based but it is very close to it, there’s only a few kinds of statements, the vast majority of things are expressions.
It makes no more sense to me for "return <expr>" to have a type than it does to make "if <expr>" or "break" or "{" or any other keyword to have a type. These are syntactic elements.
Rust's type system is clearly inspired by Hindley-Milner and most languages using such a type system either don't even have a return keyword.
Even if you disagree with this argument, this design decision has resulted in all these weird/confusing but absolutely useless code examples and there is no upside that I can see to this decision in terms of language ergonomics. What practical value is it to users to allow "return <expr>" to itself be an expression? That you can use such an "expression" as arguments to function calls with hilarious wtf consequences? It's a piece of syntactic sugar.
> don't even have a return keyword.
This is because they are not procedural languages, it has nothing to do with the type system.
> there is no upside that I can see to this decision in terms of language ergonomics.
There's tremendous upside! That's why lots of languages choose this. For example, there is no need for the ternary in Rust: if can just do that.
> What practical value is it to users to allow "return <expr>" to itself be an expression?
Code like this just works:
let guess: u32 = match guess.trim().parse() {
Ok(num) => num,
Err(_) => return,
};
That is, if return wasn't an expression, we'd have a type error: the two arms would have incompatible types. let day_number = match name {
"Sunday" => 0,
"Monday" => 1,
"Tuesday" => 2,
"Wednesday" => 3,
"Thursday" => 4,
"Friday" => 5,
"Saturday" => 6,
_ => return Err("invalid day")
};
let y = match option { Some(x) => x, None => return Err("whoops!"), };
Without a type, the None branch loses the ability to unify with the Some branch. Now you could say that Rust should just only require branches’ types to unify when all of them have a type, but the ! never type accomplishes that goal just fine.
let name = match color_code {
0 => "red",
1 => "blue",
2 => "green",
_ => "unknown",
};
The RHS of the `=>` has to be an expression, since we're assigning it to a variable. Here, you should already see one "useful" side-effect of what you're calling "syntactic elements" (I'd perhaps call them "block statements", which I think is closer to the spirit of what you're saying.) The whole `match … {}` in the example above here is an expression (we assign the evaluation of it to a variable).> What practical value is it to users to allow "return <expr>" to itself be an expression?
Now, what if I need to return an error?
let name = match color_code {
0 => "red",
1 => "blue",
2 => "green",
_ => return Err("unknown color"),
};
The expression arms need to be the same type (or what is the type of `name`?). So now the type of the last branch is !. (Which as you hopefully learned from TFA, coerces to any type, here, to &str.)There's more ways this "block statements are actually expressions" is useful. The need not be a ternary operator / keyword (like C, C++, Python, JS, etc.):
let x = if cond { a } else { b };
In fact, if you're familiar with JavaScript, there I want this pattern, but it is not to be had: const x; // but x's value will depend on a computation:
// This is illegal.
if(foo) {
x = 3;
} else {
x = 4;
}
// It's doable, but ugly:
const x = (function() { if(foo) { return 3; } else { return 4; }})();
// (Yes, you can do this example with a ternary.
// Imagine the if branches are a bit more complicated than a ternary,
// e.g., like 2 statements.)
Similarly, loops can return a value, and that's a useful pattern sometimes: let x = loop {
// e.g., find a value in a datastructure. Compute something. Etc.
if all_done {
break result;
}
};
And blocks: let x = {
// compute x; intermediate variables are properly scoped
// & cleaned up at block close.
};
> Even if you disagree with this argument, this design decision has resulted in all these weird/confusing but absolutely useless code examplesI think one can cook up weird code examples in any language.
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.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.
type Foo struct{}
func (Foo) Bar() { println("weird...") }
func main() {
([...]func(){^^len(`
`): (&Foo{}).Bar})[cap(append([]any(nil),1,2,3))]()
}
Rust programs that give unintuitive outputs or compile errors.
xyst•2h ago
steveklabnik•2h ago