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

61–70 of 155 posts

Re: Weird Expressions in Rust

#61

Post by derriz »

steveklabnik wrote: post #36
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…

Respectfully, "it makes no sense to me" isn't an argument. if and break both have types in Rust as well. > 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…

See my comment above, your example only "just works" if the enclosing function has the appropriate return type (in this case none).

So the syntactic element "return" is not just an expression - unlike other sub-expressions, it involves action at a distance - i.e. it must not just agree with it's context as part of an expression but it must agree with the enclosing fn signature.

Re: Weird Expressions in Rust

#62

Post by keybored »

gmueckl wrote: post #31
steveklabnik wrote: post #27

Earlier quoted context omitted.

> If a language that claims to be security focused 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.

"Memory safety" is an aspect of computer security. And security is the first listed value in rust's mission statement. 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.

We would need an example of puzzling code that can easily hide (security) bugs.

The submission shows weird program snippets. I don’t think it shows weird snippets that can also easily hide bugs?

Re: Weird Expressions in Rust

#63

Post by munificent »

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?

Re: Weird Expressions in Rust

#64

Post by IshKebab »

dathinab wrote: post #52
IshKebab wrote: post #14

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

yes but to be fair the blog is focused on unusual aspects of everything being an expression you still can create some more confusing things by idk. overloading some operators (but luckily not `=` and similar crazy C++ things) adding recursive macros and maybe combining it with lifetime variance and coercion edge cases, maybe sprinkle in some arcane `#[]` annotations and people with be very confused, more so then in t…

Yeah... I'm just saying I haven't seen anything close to these things:

https://github.com/denysdovhan/wtfjs

https://github.com/satwikkansal/wtfpython

Re: Weird Expressions in Rust

#65

Post by efnx »

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…

Well now we’re just talking about personal preferences, then.

Re: Weird Expressions in Rust

#66

Post by steveklabnik »

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

Re: Weird Expressions in Rust

#67

Post by bobbylarrybobby »

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…

The type of return is !, not (). Meaning there are zero instances of this type (whereas there is one instance of ()). ! can coerce to any type.

Also, the type of return is a separate matter from the type of the thing being returned. You obviously can't return Result from a function returning i32. The point of type coercion is that you can yield `return Err(...)` in one branch of a match and have it type check with the other branch(es).

Re: Weird Expressions in Rust

#68

Post by steveklabnik »

derriz wrote: post #61
steveklabnik wrote: post #36

Earlier quoted context omitted.

Respectfully, "it makes no sense to me" isn't an argument. if and break both have types in Rust as well. > 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…

See my comment above, your example only "just works" if the enclosing function has the appropriate return type (in this case none). So the syntactic element "return" is not just an expression - unlike other sub-expressions, it involves action at a distance - i.e. it must not just agree with it's context as part of an expression but it must agree with the enclosing fn signature.

I replied over there, let's keep it to that sub-tree so we both don't have to duplicate comments :)

Re: Weird Expressions in Rust

#69

Post by derriz »

steveklabnik wrote: post #60
derriz wrote: post #57

Earlier quoted context omitted.

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…

> 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. If the expression includes a return, then I cannot tell you whether the expression is well-formed.

Post reply on HN