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
Is there some meanining to the number of returns?
Weird Expressions in Rust
81–90 of 155 posts
Re: Weird Expressions in Rust
#82Earlier quoted context omitted.
Kind of like obfuscated C code I suspect.
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"
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...
Re: Weird Expressions in Rust
#83Rust 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?
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 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.
Re: Weird Expressions in Rust
#84Once I tried how many `{{{...}}}` I needed to make javac crash. It wasn’t that many.
Re: Weird Expressions in Rust
#85Earlier quoted context omitted.
Sorry for the confusion - I meant to use ! and not (). "It's not, but not due to the return, it's because you're trying to return a Result from a function that returns an i32." That's exactly my point. "return " is not just an expression which can be typed. If you tell me the types of all the identifiers used, I can look at any expression in Rust which does not include a return, and tell you if it's well typed or not…
> "return " is not just an expression which can be typed. Yes, it is, and it can. It has the type !, no matter the type of .
It only has type !, if the return type of the lexically enclosing function declaration has the same type as that of , otherwise it's illformed.
For any expression NOT involving "return", I can write, for example:
const Z =
but I cannot if contains a return embedded somewhere. The existence of a "return" somewhere in an expression changes the character of the entire expression.
I.e. there are two classes of "expressions". Those NOT containing returns (which are equivalent to the notion of "expression" in the languages that Rust was inspired by) and those containing a return somewhere in them which are subject to further rules about wellformedness.
My point is that none of this is necessary at all - you don't need to provide type rules for every lexical feature of your language to have a language with a powerful expressive type system (like Rust's).
Re: Weird Expressions in Rust
#86Earlier quoted context omitted.
Hmm my read is this is a slight overstatement - Rust was always built with the idea of expressions as first class citizens, but practicality and performance requires expression-breaking keywords like “return” which don’t fit neatly in an ML-ish language and have a few plain old hacks associated with implementing them (not “hack” as in lacking robustness; I mean theoretically/formally inelegant). Likewise there’s some…
return is an expression in Rust, and it fits in well. There are very few statements: https://doc.rust-lang.org/stable/reference/statements.html and a lot of expressions: https://doc.rust-lang.org/stable/reference/expressions.html
Steve, I know you're an authority on the language but you've dismissed the point being made here without engaging with it.
Return is a statement in the minds of most programmers, but an expression in the language. That was a very pragmatic decision that required an unintuitive implementation. As a result, we've got this post full of code that is valid to the compiler but doesn't make a lick of sense to most programmers reading it.
Re: Weird Expressions in Rust
#87Earlier quoted context omitted.
return is an expression in Rust, and it fits in well. There are very few statements: https://doc.rust-lang.org/stable/reference/statements.html and a lot of expressions: https://doc.rust-lang.org/stable/reference/expressions.html
We're speaking past each other since there's "expression" as defined in the Rust specification vs "expression" as in ordinary computer science, and Rust's use of return is certainly not an expression in the latter sense. It is shoehorned into being called an expression but it has no semantically meaningful type, it is an effect. A type is (carefully but somewhat arbitrarily) assigned to it, which is why some of those…
I do think we're speaking past each other. I don't fully agree with your "CS sense of the term," as Rust does have a semantically meaningful type: !. This is all pretty bog-standard stuff. Rust isn't doing anything weird or novel here.
Re: Weird Expressions in Rust
#88Earlier quoted context omitted.
return is an expression in Rust, and it fits in well. There are very few statements: https://doc.rust-lang.org/stable/reference/statements.html and a lot of expressions: https://doc.rust-lang.org/stable/reference/expressions.html
Steve, I know you're an authority on the language but you've dismissed the point being made here without engaging with it. Return is a statement in the minds of most programmers, but an expression in the language. That was a very pragmatic decision that required an unintuitive implementation. As a result, we've got this post full of code that is valid to the compiler but doesn't make a lick of sense to most programme…
> Return is a statement in the minds of most programmers
I would take issue with this, sure, for a lot of people, they may be bringing assumptions over from languages where assignment is a statement. That doesn't make them correct.
> required an unintuitive implementation
To some people, sure. To others, it is not unintuitive. It's very regular, and people who get used to "everything is an expression" languages tend to prefer it, I've found.
Re: Weird Expressions in Rust
#89Earlier quoted context omitted.
return is an expression in Rust, and it fits in well. There are very few statements: https://doc.rust-lang.org/stable/reference/statements.html and a lot of expressions: https://doc.rust-lang.org/stable/reference/expressions.html
We're speaking past each other since there's "expression" as defined in the Rust specification vs "expression" as in ordinary computer science, and Rust's use of return is certainly not an expression in the latter sense. It is shoehorned into being called an expression but it has no semantically meaningful type, it is an effect. A type is (carefully but somewhat arbitrarily) assigned to it, which is why some of those…
Pure functional languages have the equivalent of "never" - it's the bottom type. Indeed, the return type of `error` in Haskell is that, but also cases like predictable infinite recursion. But this semantics works great for cases like "return" and other forms of control transfer - the expression in which they appear also "never finishes" (but some other expression which contains that one as a subexpression does).
Now, yes, ideally you'd have effects in the type system so that you can express this kind of stuff with more precision. But if you restrict this to stuff like return/break/continue where the destination is statically known and can be validated, you can treat those effect types as been there, just inferred for all expressions and forbidden to cross the function boundary.
For exceptions specifically this trick no longer works because the whole point is for them to cross that boundary. But the amount of complexity this stuff adds to typing even trivial generic code is arguably too much for practical use (see also: checked exceptions in Java). In any case, in Rust you use Result types instead so those exceptions produce regular values. And although panics can be handled, they are certainly not meant to be used as a generic mechanism for transfer of control, so adding effect types for them alone is just not worth it.
Re: Weird Expressions in Rust
#90Many 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
Is there some meanining to the number of returns?
No, it's just nonsense. Same result with fewer or more returns..