On 12 June 2013 15:58, Niko Matsakis n...@alum.mit.edu wrote:
- We can have `return` just make early return from the innermost closure
as many people have requested. It'd be quite consistent.
As a recent newcomer to Rust, this would be *very* welcome. It is one
area I found particularly
After some discussion with strcat on IRC, I believe we should try to
switch to external iterators. It is true that they can be somewhat
harder to write, but the advantages are numerous:
- Easy integration with static analyses, without need for new keywords
and so forth:
- Borrow checker need
On 12/06/13 15:58, Niko Matsakis wrote:
I imagine that `for expr |pat| { body }` would be syntactic sugar
for:
let mut _iterator_ = expr;
loop {
let pat = match _iterator_.next() {
None = break,
Some(v) = v
};
body
}
I think
On Wed, Jun 12, 2013 at 1:08 PM, Gareth Smith
garethdanielsm...@gmail.comwrote:
My rust code breaks every time I get the latest incoming anyway - and it
is a pretty mechanical change.
I agree. There are no guarantees that current code will not break in future
versions of the language, until
On 12/06/2013 1:33 PM, Ziad Hatahet wrote:
On Wed, Jun 12, 2013 at 1:08 PM, Gareth Smith
garethdanielsm...@gmail.com mailto:garethdanielsm...@gmail.com wrote:
My rust code breaks every time I get the latest incoming anyway -
and it is a pretty mechanical change.
I agree. There are no
On Wed, Jun 12, 2013 at 1:58 PM, Graydon Hoare gray...@mozilla.com wrote:
Eh, unclear to me. I am partial to the existing syntax (reads like
do-notation, which I think we're keeping) and avoids breaking tons of code
and adding a keyword. Also supports no-arg iteration like:
I guess I wasn't
Hello,
Would you mind going into detail about when you need iterators that mutate
containers? I always think of iterators as having no side effects.
I ask that because if somehow you can live with only external iterators,
having one type of iterators instead of two seems to me like a great
On Tue, Jun 11, 2013 at 6:28 AM, Noam Yorav-Raphael noamr...@gmail.com wrote:
Hello,
Would you mind going into detail about when you need iterators that mutate
containers? I always think of iterators as having no side effects.
I ask that because if somehow you can live with only external
On Thu, Jun 06, 2013 at 12:09:29AM -0400, Daniel Micay wrote:
A quick terminology refresher, for those who aren't familiar with it:
Another issue is mutability, as you can write iterators that are able to
mutate
containers. With internal iterators, this is easy to do with safe code. With
On Sat, Jun 8, 2013 at 5:45 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Jun 06, 2013 at 12:09:29AM -0400, Daniel Micay wrote:
A quick terminology refresher, for those who aren't familiar with it:
Another issue is mutability, as you can write iterators that are able to
mutate
On Sat, Jun 8, 2013 at 5:56 PM, Daniel Micay danielmi...@gmail.com wrote:
Efficiency-wise, I don't think it should be a big deal because for up
to 2^32 elements it will only need a stack depth of ~32. It could be
reserving the memory in advance based on the size of the tree. The
recursive
On Sat, Jun 08, 2013 at 05:56:34PM -0400, Daniel Micay wrote:
Huh, I'm surprised by how simple it is. When I tried to do it before,
it was with the old borrow checker so I guess I could have just been
fighting with the old bugs/limitations.
The end result looks quite nice, but I confess it
On Fri, Jun 7, 2013 at 7:05 AM, Daniel Micay danielmi...@gmail.com wrote:
On Fri, Jun 7, 2013 at 12:58 AM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
The linked article contrasts them with the GoF-style iterators as well.
The Rust Iterator trait is similar to the one pass ranges
On Fri, Jun 7, 2013 at 12:10 PM, Matthieu Monrocq
matthieu.monr...@gmail.com
The extent to which you can have mutable iterators in Rust is pretty
small, because of the memory safety requirement. Iterators can't open
up a hole allowing multiple mutable references to the same object to
be
Hi,
I'm excited about Rust's iterator library based on external style.
On the other hand, I was thinking about extending current for syntax/protocol
to support returning values, which is useful for filter_map() like
functions [*0]. (It might have been discussed before, but I cannot
find it in
On Thu, Jun 6, 2013 at 8:01 PM, Vadim vadi...@gmail.com wrote:
The iterator object itself can contain a fixed size buffer into which it
copies objects before returning slice to the caller. This would work for
almost any container type.
Perhaps I'm confused about the amount of inlining that
On 05/06/2013 9:15 PM, Patrick Walton wrote:
On 6/5/13 9:09 PM, Daniel Micay wrote:
I think extending the built-in `for` loop to work with external iterators
should be considered, because right now the verbosity discourages
using them
and makes borrow checking more painful than it has to be.
On Thu, Jun 6, 2013 at 4:13 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Jun 6, 2013 at 6:19 PM, Vadim vadi...@gmail.com wrote:
Based on my experience with iterators in other languages, I would like
throw
in the following idea:
pub trait BlockyIteratorA {
///
On Thu, Jun 6, 2013 at 6:19 PM, Vadim vadi...@gmail.com wrote:
Based on my experience with iterators in other languages, I would like throw
in the following idea:
pub trait BlockyIteratorA {
/// Advance the iterator and return the next block of values.
Return empty vector when the
On Wed, Jun 5, 2013 at 9:09 PM, Daniel Micay danielmi...@gmail.com wrote:
All kinds of external iterators implement the following trait, whether
they are
a fibonacci number generator, a reverse iterator over a vector or iterator
over
a range in a sorted set:
pub trait IteratorA {
Scala has a similar design, with the following traits:
- TraversableOnce: can be internally iterated once (has a foreach() method that
takes a closure)
- Traversable: can be internally iterated unlimited times (has a foreach()
method that takes a closure)
- Iterable: can be externally iterated
On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers bill_my...@outlook.com wrote:
Scala has a similar design, with the following traits:
- TraversableOnce: can be internally iterated once (has a foreach() method
that takes a closure)
- Traversable: can be internally iterated unlimited times (has a
On Thu, Jun 6, 2013 at 11:01 PM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers bill_my...@outlook.com wrote:
Scala has a similar design, with the following traits:
- TraversableOnce: can be internally iterated once (has a foreach() method
that
The linked article contrasts them with the GoF-style iterators as well.
The Rust Iterator trait is similar to the one pass ranges (and possibly
forward ranges), but not double-ended ranges or random-access ranges. It's
the *family* of range-based iterators that makes it flexible (e.g. allowing
On Fri, Jun 7, 2013 at 12:58 AM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
The linked article contrasts them with the GoF-style iterators as well.
The Rust Iterator trait is similar to the one pass ranges (and possibly
forward ranges), but not double-ended ranges or random-access
A quick terminology refresher, for those who aren't familiar with it:
* Internal iterator: takes a closure, runs the closure until it asks to break
* External iterator: state machine, advanced by the caller in a loop
To a caller, external iterators provide the most functionality, because they
On 6/5/13 9:09 PM, Daniel Micay wrote:
I think extending the built-in `for` loop to work with external iterators
should be considered, because right now the verbosity discourages using them
and makes borrow checking more painful than it has to be.
It could treat functions as internal iterators,
27 matches
Mail list logo
