On 12/07/2013 02:08 AM, 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() { .... }
That's it! This makes it clear whenever the anomalous case nevertheless belongs
to the present application's logic (hopefully rare).
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.
Yes. Requires certainly a bit of machinary, even if thought so from the
beginning.
But optional tasks exist, semantically, whether the language acknowledges them
or not. And an Option type only solves half of the issues: namely the ones of
functions properly speaking (which compute a value); what about actions (which
perform an effect)? How can Option help the caller know, without failing
(halting the program on error), whether one has been unable to perform its task?
How can one know whether this data structure was properly updated, this visual
object moved, this msg given to the user, this file extended, renamed, deleted...?
There are also, semantically, optional data in function def input and type
defs... very annoying in a statically typed language ;-)
Denis
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
