On Mon, Dec 23, 2013 at 10:11 AM, Masklinn <[email protected]> wrote:
> > On 2013-12-23, at 05:12 , Corey Richardson <[email protected]> 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 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. Rust doesn't allow partial matches in `match`es either, for reasons, so I think it would be pretty strange to turn around and silently allow them in `let`s. The strongest arguments against IMHO are YAGNI (which is why I prefaced the whole thing with *if* there's demand for a refutable let), and the ambiguity with `if` (which is a technical issue that may or may not have a satisfactory solution). A meta-level process question: now that we have the `feature` attribute, wouldn't that be a great way to empirically decide questions like these? Implement the feature, put it behind a feature gate, and see how much use it gets, and/or if there are any problems with it? This isn't the first case where it seems like that might be more productive than trying to anticipate all of the answers from theory alone. And it seems to work pretty well for GHC. Just perhaps we could be more aggressive about removing features which weren't successful. > > 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) > If I'm understanding you correctly, this is a problem that would solve itself: if someone thinks a plain `let` is refutable and will just fail on mismatch, the compiler will quickly tell her otherwise. > > > 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. > > > On Sun, Dec 22, 2013 at 11:00 PM, Carter Schonwald > > <[email protected]> wrote: > >> Agreed! > >> > >> > >> On Sunday, December 22, 2013, Ziad Hatahet wrote: > >>> > >>> But we already have Option::unwrap_or() and Option::unwrap_or_else() > that > >>> behave similar to the 'else' syntax suggested above. > >>> > >>> -- > >>> Ziad > >>> > >>> > >>> On Sun, Dec 22, 2013 at 10:37 AM, Léo Testard <[email protected]> > >>> wrote: > >>>> > >>>> Hello, > >>>> > >>>> Le 22 déc. 2013 à 18:59, Stefan Plantikow <[email protected]> > a > >>>> écrit : > >>>> > >>>>> Hi, > >>>>> > >>>>> Am 22.12.2013 um 16:47 schrieb Gábor Lehel <[email protected]>: > >>>>> > >>>>> This is a nice idea. At first I thought it wouldn’t work with `if` > but > >>>>> in expressions `if` requires `else` so the grammar wouldn’t be > ambiguous: > >>>>> > >>>> > >>>> No, it doesn't. As long as the if's "true block" returns unit. > >>>> let foo = if ... { }; is perfectly legal, even it doesn't make much > sense > >>>> in practice. > >>>> > >>>> Leo > >>>> > >>>> _______________________________________________ > >>>> Rust-dev mailing list > >>>> [email protected] > >>>> https://mail.mozilla.org/listinfo/rust-dev > >>>> > >>> > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/rust-dev > >> > > _______________________________________________ > > Rust-dev mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
