Imagine that we have a structure of the form:
typedef struct {
int payload1;
foo *link;
int payload2;
} foo;
This structure is characterized by two things:
1) It is a singly linked list, and thus has a simple ownership
structure which can be captured by
On 06/12/13 19:11, Edward Z. Yang wrote:
Imagine that we have a structure of the form:
typedef struct {
int payload1;
foo *link;
int payload2;
} foo;
This structure is characterized by two things:
1) It is a singly linked list, and thus has a simple
Maybe the language should be changed to allow Iterator to be changed to have a
signature like this:
pub trait IteratorA {
fn next'a('a mut self) - Option'a A;
}
Then you could return the mut by reborrowing and would be able to advance the
iterator without issue afterwards.
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
OK, with a little bit of tweaking I have come up with a version
that seems to work:
struct List {
payload1: int,
next: Option~List,
payload2: f64
}
struct ListMutIterator'a {
elem: Option'a mut List
}
impl'a Iterator('a mut int, 'a mut f64)
Excerpts from Huon Wilson's message of 2013-12-06 00:26:36 -0800:
One could have an Iterator(mut int, mut int), where the references
point to just the fields. Off the top of my head:
Sure. (This is not so good when there are a lot of fields.)
impl'a Iterator('a mut int, 'a mut f64) for
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
Rust newb here. I have theoretical questions.
Recently I noticed that Higher-Kinded Types (HKTs) have been mentioned on
the mailing list a lot, but I had no idea what a HKT was, or what it might
be good for. After reading about them a little, they reminded me of C++'s
template template
Of course this leads (assuming we had a `Collection` trait) to the horrendously
ugly `Numbers::i32, ~[i32], f32, ~[f32](...)` if you wanted to be explicit.
But hopefully your code would be such that Rust could infer the bounds. This
will be alleviated in the future by associated items, but that
33 matches
Mail list logo
