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.
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.
On Sun, Dec 8, 2013 at 11:58 AM, Carter Schonwald <
[email protected]> wrote:
> Such sugar would would use some sort of monad trait right?
>
>
> On Sunday, December 8, 2013, Ziad Hatahet wrote:
>
>> On Sat, Dec 7, 2013 at 2:21 PM, Gábor Lehel <[email protected]> wrote:
>>
>>> I do wonder whether it wouldn't make sense to add sugar for Option, at
>>> least eventually. (`int?` at the type level is really nice, too... too bad
>>> it doesn't play so well with Rust's sigils. Introducing the potential
>>> confusion between `~?T` and `?~T` is probably a step too far.)
>>>
>>
>> Wouldn't it be better to add something similar to Haskell's `do` instead
>> of another sigil?
>>
>>
>> --
>> Ziad
>>
>>
> _______________________________________________
> 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
