I posted a question on the mailing list concerning this back in May:
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html
There were a couple of responses which implemented this in a macro. It
would be nice if it were at the language level though.
--
Ziad
On Fri, Dec 6, 2013 at 5:14 PM, Huon Wilson <dbau...@gmail.com> wrote:
> On 07/12/13 12:08, Jordi Boggiano wrote:
>
>> On Sat, Dec 7, 2013 at 2:01 AM, spir <denis.s...@gmail.com> wrote:
>>
>>> On 12/07/2013 01:12 AM, Gaetan wrote:
>>>
>>>> I am in favor of two version of the api: from_str which has already done
>>>> the unwrap, and a from_str_safe for instance that returns a Result or
>>>> option.
>>>>
>>> This provides the important semantic information (that I've evoked at the
>>> end end of a long earlier reply in this thread) of whether func failure
>>> is
>>> expected and belongs to the logic of the present app and we must deal
>>> with
>>> it, or not.
>>>
>>> But I'm still shared on this topic for finding it also annoying, like
>>> Simon,
>>> to have to duplicate whole catogories of such funcs (of which we cannot
>>> know
>>> in advance whther they'll fail or not), if only the interface as
>>> apparently
>>> proposed by Gaëtan.
>>>
>> Syntax sugar like this would be nice:
>>
>> let str = std::str::from_utf8("Parse this optimistically, and fail
>> otherwise");
>> // str is a string or the task fails
>>
>> vs.
>>
>> let opt_str = std::str::from_utf?("Parse this if valid"); // note the
>> question mark
>> if opt_str.is_some() { .... }
>>
>> Problem is, this sounds scary to implement at the compiler level, if
>> it's possible at all :) I am just throwing it out there for others to
>> judge.
>>
>> Cheers
>>
>>
> I personally think a better solution is something like Haskell's do
> notation[1], where you can chain several computations that return
> Option<..> such that if any intermediate one returns None, the later ones
> are not evaluated and the whole expression returns None, which saves having
> to call .get()/.unwrap()/.expect() a lot.
>
> This can work for types like Result too (in fact, the Haskell
> implementation of `do` is sugar around some monad functions, so any monad
> can be used there; we currently don't have the power to express the monad
> typeclass/trait in Rust so the fully general form probably isn't possible
> as a syntax extension yet, although a limited version is).
>
>
> Huon
>
> [1]: http://en.wikibooks.org/wiki/Haskell/do_Notation
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
