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

111–120 of 155 posts

Re: Weird Expressions in Rust

#111

Post by steveklabnik »

munificent wrote: post #108
steveklabnik wrote: post #66

Earlier quoted context omitted.

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

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.

Ahhh yeah, no worries!

Re: Weird Expressions in Rust

#112

Post by rtpg »

derriz wrote: post #57
bobbylarrybobby wrote: post #38

Earlier quoted context omitted.

The issue with `return expr` not having a type is that you lose the ability to write something like 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.

I'm responding here because so many replies are making the same point. In your particular example, let's put your example into a context. Is fn foo(option: Option ) -> i32 { let y = match option { Some(x) => x, None => return Err("whoops!"), }; return 1; } well typed? It should be if we are to believe that "return " is an expression of type () - but, naturally, it causes a compilation error because the compiler speci…

When discussing well typed-ness, and with more complex languages where you have weird undecideable components, you can end up with a notion of "Well typed" as follows:

e: T is well typed _if_ the end result of e would be of type T

(end result being hand-wave-y)

It's not a guarantee that e is a value of a certain type, but a guarantee that if e is a value in the first place, then it will be a certain type. You sidestep having to prove the halting nature of e.

This leaves a nice spot for computation that doesn't complete!

    let y = return 1
    f(y)
y could be any type, and it's well typed, because you're never in a secnario where f(y) will be provided a value of the wrong type.

Well-typed-ness, by my understanding in more complex type system, is not a guarantee of control flow, but a guarantee that _if_ we evaluate some expression, then it will be fine.

And so... you can put `!` as a type in your system, treat return as an expression, and have a simpler semantic model, without really losing anything. Less moving parts, etc.... that's my read of it anyways.

Re: Weird Expressions in Rust

#113

Post by [deleted] »

tialaramex wrote: post #109
throwawaymaths wrote: post #33

Earlier quoted context omitted.

its not just that some things you would usually think are control flow are expressions, its also that there are unusual rules around coercing the `noreturn` type.

The only "unusual" rule here is that Rust offers the zero type addition, but does not provide the (much more complicated) other type additions So Rust does have: String + ! = String But Rust doesn't have: String + i32 = Either Note that the never type ! isn't special here, Rust will also cheerfully: String + Infallible = String or if you were to define your own empty type like so: enum MyEmptyType {} // MyEmptyType h…

[deleted]

Re: Weird Expressions in Rust

#114

Post by nikolayasdf123 »

nemo1618 wrote: post #17
nikolayasdf123 wrote: post #8

this is why I like Go

I wonder, what's the "weirdest" expression in Go? Here's one: type Foo struct{} func (Foo) Bar() { println("weird...") } func main() { ([...]func(){^^len(` `): (&Foo{}).Bar})[cap(append([]any(nil),1,2,3))]() }

this the worst? not too bad. fairly comprehensible.

Re: Weird Expressions in Rust

#115

Post by kuschku »

rtpg wrote: post #110
steveklabnik wrote: post #87

Earlier quoted context omitted.

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.

I do wonder how many languages have the "never returns" type explicitly available. Typescript and Rust.... Haskell has bottom but I wonder semantically how much space there is between bottom and "never return". Obviously laziness makes things weird. This is what I find interesting in this generation of languages though. Any C programmer understands the notion of an infinite loop, and the value of conditional expressi…

Kotlin also has this type, it's called "Nothing".

https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-nothin...

As you can never get a value of type nothing, it can coerce into anything, just like rust's ! or () or typescripts never.

Re: Weird Expressions in Rust

#117

Post by Timwi »

jerf wrote: post #11
ibotty wrote: post #10

Earlier quoted context omitted.

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

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…

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

Re: Weird Expressions in Rust

#118

Post by san1927 »

steveklabnik wrote: post #6

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 was a keyword to print stuff to the screen. Hence the joke, https://en.wikipedia.org/wi…

love this one thats a really underrrated fact

Re: Weird Expressions in Rust

#119

Post by Timwi »

int_19h wrote: post #92
missinglugnut wrote: post #86

Earlier quoted context omitted.

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…

We've been going down this road for a long time now. E.g. "throw" is a (void-typed) expression in C++ already for similar reasons, although it doesn't go far enough without a proper bottom type. C# took it further and added the type so that you can write things like e.g. `x = y ?? throw new Error(...)`. There's no obvious reason why "return" should be conceptually different. A better question at this point, arguably,…

I considered whether to mention C# in this thread but initially decided against it because it doesn't actually have a bottom type. You can't assign a throw expression to an implicitly-typed variable, or anywhere else where it is needed to infer a type. You can only use it in places where a type is already known so the throw expression can be coerced to it.

In fact, I recently ran into the finding that you can't use it with logical operators either: `return myBool && throw...` doesn't work. I assume that's because && can be used with many types even if the first operand is a bool, but the compiler error message doesn't explain that, it just says throw is an invalid token here, and if you parenthesize it, it says a throw expression can't be used in this context. I was very surprised by this seemingly arbitrary limitation.

Re: Weird Expressions in Rust

#120

Post by nialv7 »

kuschku wrote: post #115
rtpg wrote: post #110

Earlier quoted context omitted.

I do wonder how many languages have the "never returns" type explicitly available. Typescript and Rust.... Haskell has bottom but I wonder semantically how much space there is between bottom and "never return". Obviously laziness makes things weird. This is what I find interesting in this generation of languages though. Any C programmer understands the notion of an infinite loop, and the value of conditional expressi…

Kotlin also has this type, it's called "Nothing". https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-nothin... As you can never get a value of type nothing, it can coerce into anything, just like rust's ! or () or typescripts never.

I recently realized (by playing with Lean) that coercing of "!" is because of the principle of explosion [1]. Basically propositions are types in Lean, and proofs are instances of those types. A proposition that is false doesn't have any instances, so they are like "!". Principle of explosion says ∀ P, False -> P, which is exactly the type signature for "!" coercing.

[1]: https://leanprover-community.github.io/mathlib4_docs/Init/Pr...

Post reply on HN