On 12/07/2013 12:57 PM, Devin Jeanpierre wrote:
On Sat, Dec 7, 2013 at 3:33 AM, spir <[email protected]> wrote:But the issue exists anyway... dunno about solution. In fact we'd ned to invert the logic: instead of: x = foo() // Option element wrapping possible result x = foo().unwrap() // bare result think: x = foo().option() // Option element wrapping possible result x = foo().direct() // bare resultIn what way is this better? Seems to me it's a basically functionless layer of abstraction, and things that don't always have a usable result should always return option, and if you want them to fail, you can request failure via .unwrap(). If this is too verbose, then we should make it less verbose, e.g. `x = *foo()` or something. Or we can keep the status quo, which seems fine to me. I'm not really picky about verbosity.
Possibly it's clear for you if you are used to the Option workaround, from other languages (I have been, in fact, from Ocaml). But with this solution the code does not say what it means (lol!), not to speak of idioms repeted everywhere in source as evoked by Gaetan (and similar to Java, in fact (lol bis!)). However, in my view, this is not a question of verbosity, but of having source code match (sic!) the semantics, what we actually mean.
A solution would be to have such functions return either a bare result, or an Option wrapping a possible result, depending on how they are called (instead of '?', there may be a bool param, why not?). But not a functional either/or, this would doubly wrap the result! Instead really either one or the other. Indeed, this is not possible in standard in a statically typed language, reason for other solutions, such as one evoked in a previous mail: have an 'anomaly' flag somewhere, possibly a bare pointer for error data, and minimal syntactic support. In fact, simple error management (I don't mean exception handling) may require being taken into account in language design righ from the start, even more than testing & debugging, for instance; but all 3 of those "meta-programming" dimensions are related anyway.
Denis _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
