Why not have it be an auto-implemented trait like Send or Freeze?
On Mon, Dec 9, 2013 at 10:05 AM, Simon Sapin <[email protected]> wrote: > 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
