I agree with Simon that doubling the API is inelegant. I think the solution
is adding sugar to make working with Option/Result easier -
(semi-)independent of the foo/foo_opt issue, I find working with Option
pretty painful.
I prefer the Haskell do sugar to refutable patterns in let. Similar in
I can see how '?.' would work when foo() returns a struct, but what about
non-struct types, e.g. Optioni32 ? Also, you'd still have to deal with
'None' at the end of the chain. I think in most cases I'd rather have it
fail.
I also don't really like refutable let-patterns proposal, because
I think that you eventually have to deal with the Some or None-ness of an
expression is an advantage of the ? operator, it means you can't ignore
failure, but you don't have to deal with it at every step of a compound
expression. Using an operator for unwrap has the same disadvantage as plain
On Tue, Jan 7, 2014 at 6:39 PM, Nick Cameron li...@ncameron.org wrote:
I think that you eventually have to deal with the Some or None-ness of an
expression is an advantage of the ? operator, it means you can't ignore
failure, but you don't have to deal with it at every step of a compound
On 8/01/2014, at 3:39 pm, Nick Cameron li...@ncameron.org wrote:
I think that you eventually have to deal with the Some or None-ness of an
expression is an advantage of the ? operator, it means you can't ignore
failure, but you don't have to deal with it at every step of a compound
I realized something. A good near term working solution could make use of
the pending procedural macros to make a nicer syntax for the and_then
procedures!
(or could the current syntax rules style macros work with that even?). Not
sure If i'll have the time to do that experiment,
but throwing
Sorry, I didn't mean ignore errors as in unsafe, I meant that it allows the
programmer to write code without having the error case be explicit. This is
the (well, one of the) problems with null pointers in C and Java.
You make a good point about errors from the API, and I guess this
highlights a
On Dec 23, 2013, at 11:23 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 12/23/13 4:12 AM, Gábor Lehel wrote:
I don't like either that (a) the possible failure is silent, and
refutable lets look the same as irrefutable ones, nor (b) baking fail!()
into the semantics. Haskell has these
This is a very good point. Many of those same issues apply in Haskell too.
Additionally, the examples people have given for refutable let thus far all
seem to be special cases of a do notation / computation expression /
monadic abstraction.
That said, unless a special builtin trait is made,
Hi,
Am 23.12.2013 um 10:11 schrieb Masklinn maskl...@masklinn.net:
On 2013-12-23, at 05:12 , Corey Richardson co...@octayn.net wrote:
I find the ability to have refutable let
I may have missed it, but is there a reason not to have just that? Make
let similar to Erlang’s `=` and fail
On Mon, Dec 23, 2013 at 10:11 AM, Masklinn maskl...@masklinn.net wrote:
On 2013-12-23, at 05:12 , Corey Richardson co...@octayn.net wrote:
I find the ability to have refutable let
I may have missed it, but is there a reason not to have just that? Make
let similar to Erlang’s `=` and fail
On Sun, Dec 22, 2013 at 7:37 PM, Léo Testard leo.test...@gmail.com wrote:
Hello,
Le 22 déc. 2013 à 18:59, Stefan Plantikow stefan.planti...@gmail.com a
écrit :
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel glaebho...@gmail.com:
This is a nice idea. At first I thought it wouldn’t
I may have missed it, but is there a reason not to have just that? Make
let similar to Erlang’s `=` and fail on refutation?
Erlang is designed around handling failure. It has links, monitors,
supervisors, and so forth. Rust has only some very basic tools for
catching the failure of a task.
On 12/23/13 4:12 AM, Gábor Lehel wrote:
I don't like either that (a) the possible failure is silent, and
refutable lets look the same as irrefutable ones, nor (b) baking fail!()
into the semantics. Haskell has these also and I think it's a wart. The
proposed syntax solves both issues.
For what
that seems like a reasonable balance
On Mon, Dec 23, 2013 at 12:23 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/23/13 4:12 AM, Gábor Lehel wrote:
I don't like either that (a) the possible failure is silent, and
refutable lets look the same as irrefutable ones, nor (b) baking fail!()
the OCaml compiler complains with a warning if you use a refutable
pattern in `let`.
And what does OCaml do at runtime if the pattern is refuted?
On Mon, Dec 23, 2013 at 12:23 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/23/13 4:12 AM, Gábor Lehel wrote:
I don't like either that (a)
On 12/23/13 10:48 AM, Benjamin Striegel wrote:
the OCaml compiler complains with a warning if you use a refutable
pattern in `let`.
And what does OCaml do at runtime if the pattern is refuted?
Throws.
Patrick
___
Rust-dev mailing list
That seems like a nice compromise, but I don't think it's a good one.
Either you intended the pattern to be refutable or you didn't. If you
didn't and it is, you should get an error, not a warning. If you did, you
shouldn't get a warning at all. Are you going to put a compiler pragma to
disable
I too think it would be a big mistake to allow let patterns to be
refutable, when we've already tried and rejected allowing the same in match
statements (ancient Rust history quiz: who else remembers `match check`?).
On Mon, Dec 23, 2013 at 2:44 PM, Gábor Lehel glaebho...@gmail.com wrote:
That
On 23/12/2013 20:55, Benjamin Striegel wrote:
I too think it would be a big mistake to allow let patterns to be
refutable, when we've already tried and rejected allowing the same in
match statements (ancient Rust history quiz: who else remembers `match
check`?).
For those of us that were not
For those of us that were not around or do not remember, can you explain
what was tried and rejected?
Heh, it was so long ago that I forgot that the `match` keyword used to be
`alt`. Here's the relevant section from the 0.1 manual (Jan 2012):
Using `match` works well enough, but if there's demand for a refutable
`let` which is lighter-weight, what about:
let Some(result) = from_utf8(some_bytes) else fail!();
In other words, if the `let` pattern is refutable, you have to provide
something `else` with return type `!` as the
That is pretty elegant.
Le 22 déc. 2013 16:47, Gábor Lehel glaebho...@gmail.com a écrit :
Using `match` works well enough, but if there's demand for a refutable
`let` which is lighter-weight, what about:
let Some(result) = from_utf8(some_bytes) else fail!();
In other words, if the `let`
I quite like this proposal, though I'd suggest that the else clause
is evaluated as the value for when the pattern fails. `!` would always
be substitutable there.
On Sun, Dec 22, 2013 at 10:47 AM, Gábor Lehel glaebho...@gmail.com wrote:
Using `match` works well enough, but if there's demand for
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel glaebho...@gmail.com:
Using `match` works well enough, but if there's demand for a refutable `let`
which is lighter-weight, what about:
let Some(result) = from_utf8(some_bytes) else fail!();
This is a nice idea. At first I thought it
Hello,
Le 22 déc. 2013 à 18:59, Stefan Plantikow stefan.planti...@gmail.com a écrit :
Hi,
Am 22.12.2013 um 16:47 schrieb Gábor Lehel glaebho...@gmail.com:
This is a nice idea. At first I thought it wouldn’t work with `if` but in
expressions `if` requires `else` so the grammar wouldn’t
But we already have Option::unwrap_or() and Option::unwrap_or_else() that
behave similar to the 'else' syntax suggested above.
--
Ziad
On Sun, Dec 22, 2013 at 10:37 AM, Léo Testard leo.test...@gmail.com wrote:
Hello,
Le 22 déc. 2013 à 18:59, Stefan Plantikow stefan.planti...@gmail.com a
Agreed!
On Sunday, December 22, 2013, Ziad Hatahet wrote:
But we already have Option::unwrap_or() and Option::unwrap_or_else() that
behave similar to the 'else' syntax suggested above.
--
Ziad
On Sun, Dec 22, 2013 at 10:37 AM, Léo Testard
leo.test...@gmail.comjavascript:_e({}, 'cvml',
On Dec 17, 2013, at 11:37 AM, Stefan Plantikow stefan.planti...@gmail.com
wrote:
Hi,
Am 17.12.2013 um 20:10 schrieb Corey Richardson co...@octayn.net:
On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
stefan.planti...@gmail.com wrote:
Hi,
Am 09.12.2013 um 16:53 schrieb Damien
Hi,
Am 17.12.2013 um 20:10 schrieb Corey Richardson co...@octayn.net:
On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
stefan.planti...@gmail.com wrote:
Hi,
Am 09.12.2013 um 16:53 schrieb Damien Radtke damienrad...@gmail.com:
I have no idea if it would be feasible in the standard
On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
stefan.planti...@gmail.com wrote:
Hi,
Am 09.12.2013 um 16:53 schrieb Damien Radtke damienrad...@gmail.com:
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.
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
On 12/09/2013 04:53 PM, 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
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
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
On Mon, Dec 9, 2013 at 10:53 AM, Damien Radtke damienrad...@gmail.com 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
On Sat, Dec 7, 2013 at 2:21 PM, Gábor Lehel illiss...@gmail.com 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
On Sun, Dec 8, 2013 at 10:26 AM, Ziad Hatahet hata...@gmail.com wrote:
On Sat, Dec 7, 2013 at 2:21 PM, Gábor Lehel illiss...@gmail.com 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
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
illiss...@gmail.comjavascript:_e({}, 'cvml', 'illiss...@gmail.com');
wrote:
I do wonder whether it wouldn't make sense to add sugar for
On 07/12/2013 01:07, spir wrote:
Maybe it's only me, but this not at at all clear to my eyes. My imagined soluton
(for a totally different lang) was something like this, on the caller side:
ucodes = s.utf8_decode()! // source should be correct, error on
failure
ucodes =
On 07/12/2013 01:14, Huon Wilson wrote:
I personally think a better solution is something like Haskell's do
notation[1], where you can chain several computations that return
Option.. such that if any intermediate one returns None, the later
ones are not evaluated and the whole expression returns
On 07/12/13 20:55, Simon Sapin wrote:
On 07/12/2013 01:14, Huon Wilson wrote:
I personally think a better solution is something like Haskell's do
notation[1], where you can chain several computations that return
Option.. such that if any intermediate one returns None, the later
ones are not
On 12/07/2013 10:53 AM, Simon Sapin wrote:
On 07/12/2013 01:07, spir wrote:
Maybe it's only me, but this not at at all clear to my eyes. My imagined soluton
(for a totally different lang) was something like this, on the caller side:
ucodes = s.utf8_decode()!// source should be correct,
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
On Sat, Dec 7, 2013 at 3:33 AM, spir denis.s...@gmail.com 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
What do you think about implicit unwrap? I don't know if this could be done
but I find it pretty elegant.
It's a design choice. For me all API should follow the same pattern, not
some returning bare result without failure case, or return a boolean and
modify the content of a pointer, or use
On 12/07/2013 12:57 PM, Devin Jeanpierre wrote:
On Sat, Dec 7, 2013 at 3:33 AM, spir denis.s...@gmail.com 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
I agree with this proposal. I also strongly agree with spir that we should
distinguish programmer errors from legitimate result possibilities. A
function should only fail directly if, were it to return a `None` or `Err`,
the only reasonable the thing caller could do would be to fail itself.
We have some functions and methods such as
[std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html)
that may succeed and give a result, or fail when the input is invalid.
1. Sometimes we assume the input is valid and don’t want to deal with
the error case. Task
I'm in favor of this but it makes things less pretty. Is the choice
really between pretty and fast?
On Fri, Dec 6, 2013 at 3:41 PM, Simon Sapin simon.sa...@exyr.org wrote:
We have some functions and methods such as
On Fri, Dec 6, 2013 at 3:41 PM, Simon Sapin simon.sa...@exyr.org wrote:
We have some functions and methods such as
[std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html)
that may succeed and give a result, or fail when the input is invalid.
1. Sometimes we
On 12/06/2013 12:41 PM, Simon Sapin wrote:
We have some functions and methods such as
[std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html)
that may succeed and give a result, or fail when the input is invalid.
1. Sometimes we assume the input is valid and
On 06/12/2013 20:48, Corey Richardson wrote:
I'm in favor of this but it makes things less pretty. Is the choice
really between pretty and fast?
I don’t think this is about speed. My concern is that having two
almost-identical names for functions that do almost the same thing is
not a good
On 06/12/2013 20:55, Léo Testard wrote:
Hi,
Just a suggestion, don't know what it's worth...
For the not helpful error message thing, couldn't we extend the
option API, to be able to specify at the creation of a None value
the error string that will be displayed if one calls unwrap() on this
FYI, there's already a method on Option that is unwrap() with an error
message: expect().
Personally, I prefer making functions that don't fail and use Option or
Result and then composing them with functions that fail for certain
outputs, but I think I'm in the minority there.
On Fri, Dec 6,
On 06/12/2013 21:44, Brian Anderson wrote:
I agree in this case (and probably a lot of cases), especially since
this is a relatively uncommon operation and since (I think) we're
prefering 'get' to 'unwrap' and that's even shorter.
There are some cases where I think failure is the right option
On 06/12/2013 21:50, Eric Reed wrote:
Personally, I prefer making functions that don't fail and use Option or
Result and then composing them with functions that fail for certain
outputs, but I think I'm in the minority there.
Yes, this is what I’m suggesting.
--
Simon Sapin
Why not use Result instead of Option for these types of things? Result is
already defined to be able to return error codes using Err. The only way to
indicate an error when returning an Option is to return None which doesn't
allow for that. Also, IMO, None doesn't necessarily mean error to me.
I also find the repeatition of unwrap all over the code being quite nasty
Most of the time the result is just unwrapped without taking into account
the error case, so i think the usage of Option or Result useless.
I think a good solution exits and can make the code more maintainable, and
easier
Isnt a way for Option to unwrap implicitely when check on error state is
not done ? That would make the code less verbose but still allow the dev to
check for error if want?
Le 7 déc. 2013 01:12, Gaetan gae...@xeberon.net a écrit :
I also find the repeatition of unwrap all over the code being
On 07/12/2013 00:12, 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 is what we have now. (Eg. from_utf8() and from_utf8_opt())
The point of my initial email was to argue
On 12/06/2013 09:41 PM, Simon Sapin wrote:
We have some functions and methods such as
[std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html)
that may succeed and give a result, or fail when the input is invalid.
1. Sometimes we assume the input is valid and
On 07/12/2013 00:49, spir wrote:
About the latter, in particular it should be obvious in code, without knowledge
of language arcanes or weird idioms, that (or whether) the caller expects a
success unconditionally -- because (and in other words that) the anomalous case
just does not belong to
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
On 12/07/2013 01:55 AM, Simon Sapin wrote:
On 07/12/2013 00:49, spir wrote:
About the latter, in particular it should be obvious in code, without knowledge
of language arcanes or weird idioms, that (or whether) the caller expects a
success unconditionally -- because (and in other words that)
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
On 07/12/13 12:08, 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.
On Sat, Dec 7, 2013 at 2:07 AM, spir denis.s...@gmail.com wrote:
Maybe it's only me, but this not at at all clear to my eyes. My imagined
soluton (for a totally different lang) was something like this, on the
caller side:
ucodes = s.utf8_decode()! // source should be correct,
Is do-notation in Haskell similar as: try{ block } ?
2013/12/7 Huon Wilson dbau...@gmail.com
On 07/12/13 12:08, 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
I posted a question on the mailing list concerning this back in May:
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html
There were a couple of responses which implemented this in a macro. It
would be nice if it were at the language level though.
--
Ziad
On Fri, Dec 6, 2013 at
On 12/6/13 6:46 PM, Niko Matsakis wrote:
I agree. I've personally been moving towards `ResultT, ()` in
preference to `OptionT` when one of the branches reflects an
error. It's worth noting that the compiler could still optimize this
into a pointer-null-pointer representation, though I doubt it
On 7 Dec 2013, at 10:47 am, Simon Sapin simon.sa...@exyr.org wrote:
This is why we have methods like .map() and .and_then()
I like using these higher order functions, but I run into lots of issues with
moved values because we don’t have once functions. I end up having to use
matches, which
There was a whole thread about the need for once-stack-closures. They are
really vital for simple programming with higher-order functions such as
these. I'm not optimistic about them being added though :-(
On Sat, Dec 7, 2013 at 8:15 AM, Brendan Zabarauskas bjz...@yahoo.com.auwrote:
On 7 Dec
Especially if ResultT, () is optimized into a single word, it seems ideal
to me to get rid of str::from_utf_opt([u8]) - Option~str and just have
str::from_utf([u8]) - Result~str, (). This makes simple programs that
don't care about error handling a little more complicated, of course, since
it
74 matches
Mail list logo
