That page illustrates an important distinction between expression based languages and procedural ones. You couldn't do that in an expression, as it wouldn't type check without a value for the None case.
When I first saw Option it seems like a great way to force handling of the None case, either explicitly in place, or by passing on a mapped option as a return value (monadic composition make this a nice thing).
This resembles how exceptions are handled in most procedural languages, either you catch it and handle it, or you don't, and someone else gets to do it further up the call stack.
The example on that page looks like the equivalent of an empty catch block. It's almost certainly a bad idea that will bite you in the ass some day.
Granted. But a unit expression is only useful for its side effect so I guess I put that in the gray area between paradigms, not really in the spirit of only evaluating expressions. Which brings us back the point of my comment: It's almost certainly a bad idea.
> You couldn't do that in an expression, as it wouldn't type check without a value for the None case.
Of course you could. If there is no `else` (which there can be, fwiw, just as the else case is optional in a regular if/else expression), the value of the None case is Unit: http://is.gd/Zdgc3D
This is not accurate. Rust is an expression based language, and `if let`s are expressions. If an `if` or `if let` returns (), it does not need an else.
I initially considered writing that, but it depends on what the original poster means by "expression-based language" and they haven't made that clear: in Rust, a function is a sequence of statements. An assignment is a statement for instance, not an expression. To me an expression-based language is something like Haskell or Elm, not only do you have ubiquitous expressions (which Rust does have) there's really no such thing as a statement, a program (or function) simply is an expression (possibly with multiple components) this Rust:
let a = 1;
let b = 2;
a + b
is 3 statements. The equivalent Elm or Haskell is a single expression:
Everything at the function level that isn't `let` is an expression. And that `let` is not an expression is just an aspect of Rust that reduces boilerplate and rightward drift; the block containing those three statements in your example is still an expression which evaluates to the same thing as the Haskell below.
The original commenter seems to mean 'purely functional' rather than 'expression based'. OCaml uses `let in`, but still has side effects.
The issue you're talking about is purity (not having side effects). Many expression based languages have side effects, such as Rust, OCaml, or Common Lisp.
When I first saw Option it seems like a great way to force handling of the None case, either explicitly in place, or by passing on a mapped option as a return value (monadic composition make this a nice thing).
This resembles how exceptions are handled in most procedural languages, either you catch it and handle it, or you don't, and someone else gets to do it further up the call stack.
The example on that page looks like the equivalent of an empty catch block. It's almost certainly a bad idea that will bite you in the ass some day.