Hi,
Am 23.12.2013 um 10:11 schrieb Masklinn <maskl...@masklinn.net>:
>
> On 2013-12-23, at 05:12 , Corey Richardson <co...@octayn.net> wrote:
>
>> I find the ability to have refutable let
>
> I may have missed it, but is there a reason not to have just that? Make
> let similar to Erlang’s `=` and fail on refutation?
>
I didn’t understand this to be about wether let should accept refutable
patterns in general. Rather this is about wether there should be additional
syntax for refutable patterns. The decision to make irrefutable let the default
seems reasonable as it avoids silent breakage when new variants are introduced
for an enum type.
> You said you find the basic let’s irrefutability to be a useful property
> but have not explained why, and why it makes sense to introduce a
> separate-but-similar construct with subtly different semantics
> (I also see this as a possible failure, would users of the language
> really expect `let` to be irrefutable and `let [else]` to be refutable,
> or would they expect `let [else]` to allow returning a value and `let`
> to just fail on mismatch? If such different semantics are desired,
> I’d suggest using a different keyword entirely)
>
>> more compelling than the
>> ability to work around it with functions wrapping `match`
>
> That assertion seems ill supported so far: just about every example is
> in terms of `Option`, and `Option` is the one type which does not need a
> refutable let, owing to its truckload of convenience methods covering
> just about every basic use cases the only reasons to use a `match` with
> Option are personal preferences and insufficient knowledge of the type.
>
Sure, this discussion has used Option as a running example. I guess the more
interesting use case is a library defined type without an unwrap() or similar
method. A client of the library could of course implement his own helper method
to solve that issue - or just use a variant of let with refutable patterns.
The benefit of the refutable patterns would be less boilerplate for helper
methods like unwrap(), the ability to „unwrap“ any type, and a nice syntax for
trying multiple values in succession ( let Some(x) =? try_1(), try_2(), fail()
).
Cheers,
Stefan.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
