Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weird Expressions in Rust

wakunguma.com

Post reply on HN
Print view View original

71–80 of 155 posts

Re: Weird Expressions in Rust

#71

Post by steveklabnik »

derriz wrote: post #69
steveklabnik wrote: post #60

Earlier quoted context omitted.

> Is ... well typed? 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. This works: fn foo(option: Option ) -> Result { let y = match option { Some(x) => x, None => return Err("whoops!"), }; return Ok(1); } > It should be if we are to believe that "return " is an expression of type () It is not, it is an expression of type !. This type unifies with…

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 .

Re: Weird Expressions in Rust

#73

Post by pitaj »

munificent wrote: post #63

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…

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

Re: Weird Expressions in Rust

#74

Post by xg15 »

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?

Re: Weird Expressions in Rust

#75

Post by Analemma_ »

xg15 wrote: post #74

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?

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.

Re: Weird Expressions in Rust

#76

Post by iforgotpassword »

saghm wrote: post #55
jerf wrote: post #11

Earlier quoted context omitted.

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 Engli…

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.

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

Re: Weird Expressions in Rust

#77

Post by lacker »

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.

Re: Weird Expressions in Rust

#78

Post by 01HNNWZ0MV43FF »

ramon156 wrote: post #4

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.

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"

Re: Weird Expressions in Rust

#79

Post by wredcoll »

deathanatos wrote: post #40
derriz wrote: post #32

Earlier quoted context omitted.

That sounds superficially reasonable to me and I'm all for regularity in programming language semantics but on thinking about it further, I actually think it's a design flaw. It makes no more sense to me for "return " to have a type than it does to make "if " 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…

We can use match to do pattern matching: 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…

I appreciate, so much, that rust is slowly evolving into perl.

Re: Weird Expressions in Rust

#80

Post by AIPedant »

steveklabnik wrote: post #53
AIPedant wrote: post #47

Earlier 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

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 examples involving "return" are particularly goofy. It is not material for most programs since it only comes up with intentional misuse of the keyword. But "return" does not make sense in functional languages with true first-class expressions - functions don't return values, they get evaluated and the frame destruction / etc are all abstracted away. It makes sense in Rust because expressions in the CS sense of the term are ultimately not first class.
Post reply on HN