This is a very good point. Many of those same issues apply in Haskell too.
Additionally, the examples people have given for refutable let thus far all seem to be special cases of a do notation / computation expression / monadic abstraction. That said, unless a special builtin trait is made, that line of recommendation seems like it's not viable until rusts type system gets a bit more enriched, what with higher kinded types being needed etc. On Tuesday, December 24, 2013, Lars Bergstrom wrote: > On Dec 23, 2013, at 11:23 AM, Patrick Walton > <[email protected]<javascript:;>> > wrote: > > > > On 12/23/13 4:12 AM, Gábor Lehel wrote: > >> I don't like either that (a) the possible failure is silent, and > >> refutable lets look the same as irrefutable ones, nor (b) baking fail!() > >> into the semantics. Haskell has these also and I think it's a wart. The > >> proposed syntax solves both issues. > > > > For what it's worth, Rust's pattern matching is pretty heavily based on > OCaml's and the OCaml compiler complains with a warning if you use a > refutable pattern in `let`. > > At the time SML and Caml made those decisions, neither language provided > stack backtraces. According to the folks I've asked about it, the reason > that refutable patterns in let bindings were left in there with a warning > was that if you called Option.valOf on NONE, you just get: > uncaught exception Option > raised at: Basis/Implementation/option.sml:17.25-17.31 > - > > And the debugging is a real pain because "you failed in the basis library" > doesn't help you track it down and you're pretty much stuck with > printf-debugging (because there were also no debuggers / breakpoints). > Whereas if you fail on the binding, the exception is thrown on the line > where the binding attempt occurred: > uncaught exception Bind [nonexhaustive binding failure] > raised at: stdIn:1.10-3.10 > - > > This was supposedly an especially contentious decision in the SML language > design meetings. > > Given that modern ML implementations at least have the option to provide > stack backtraces in debugging builds, the people I've talked to have said > they would probably not allow refutable patterns today because large > codebases written in this style end up with hundreds to thousands of > "ignorable warnings" in their output, which both looks ugly and drowns out > any real warnings. But, they can't change things now because it would break > too much legacy code. > - Lars > _______________________________________________ > Rust-dev mailing list > [email protected] <javascript:;> > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
