>
> let result: ~str = from_utf8(...);
> let result: Option<~str> = from_utf8(...);
That was what I called "implicit unwrap". I however recommend ``let result
= from_utf8(...)`` to be the unwrapped version (ie, result is ~str)
Do you think it is possible to add this syntaxic sugar?
fn any_function() -> Result<~str>
{
...
}
// When called :
let s = any_function(); // unwrap() is automatically called, s is a ~str
let res = any_function?(); // unwrap is not called, res is a Result<~str>
let res2: Result<~str> = any_function(); // unwrap is not called, res is a
Result<~str>
if res.is_ok() {
let s2 = res.unwrap()
}
Or maybe a simpler version, but the semantic is reversed, where a?() means
a().unwrap():
let res = any_function(); // unwrap is not called, res is a Result<~str>
let s = any_function?(); // unwrap() is automatically called, s is a ~str
-----
Gaetan
2013/12/9 Simon Sapin <[email protected]>
> On 09/12/2013 15:53, Damien Radtke wrote:
>
>> I have no idea if it would be feasible in the standard library, but
>> wouldn't the ideal solution be having one function (e.g. from_utf8())
>> that could return two possible values, a bare result and an Option?
>> Letting the compiler decide which version to use based on type inference
>> like this:
>>
>> let result: ~str = from_utf8(...);
>> let result: Option<~str> = from_utf8(...);
>>
>> Assuming both of them are passed invalid UTF8, then the first version
>> would fail, but the second version would just return None.
>>
>> Again, I don't know if it's possible given the current implementation,
>> but I do think it would be helpful to have a picture of the ideal, and
>> then decide on whatever solution comes closest.
>>
>
> It is possible to have a generic return value, see for example the
> .collect() method of iterators.
>
> https://github.com/mozilla/rust/blob/4e0cb316fc980f00e1b74f3fdb7a84
> 2b540be280/src/libstd/iter.rs#L447
>
> But it involves creating a trait, and implementing it for every supported
> type. IMO it’s a lot more involved than what we would want for every
> operation that may fail on invalid input.
>
>
>
> As a side note, even if the standard library sticks with two variants
>> for each option function, I would prefer the default one return an
>> Option and have the variant fail on invalid input. Task failure at
>> runtime is a nastier surprise than an invalid type error at compile
>> time, especially for new users who aren't entirely sure of the difference.
>>
>
> --
> Simon Sapin
>
> _______________________________________________
> 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
