Rust for C++ programmers – part 2: control flow

Re:Rust for C++ programmers – part 2: control flow by acqq on Sunday April 20, 2014 @03:56AM (#7616185)

I have rather questions like: Why all.inter().enumerate() and not just all.enumerate() ? Why for a in all.iter() and not simply for a in all ?

Apparently is the language clever enough to match the types (which is good), why isn't than simply clever enough to recognize then that in on the array needs the iteration? Why isn't possible to directly enumerate the array?

Even (at least this one) C++ has something simple:

http://msdn.microsoft.com/en-us/library/jj203382.aspx

    for( auto y : x ) { // Copy of 'x', almost always undesirable
        cout << y << " ";
    }

    for( auto &y : x ) { // Type inference by reference.
        // Observes and/or modifies in-place. Preferred when modify is needed.
        cout << y << " ";
    }

    for( const auto &y : x ) { // Type inference by reference.
        // Observes in-place. Preferred when no modify is needed.

Not even "in" keyword is used there but it still allows iterations through anything that can be iterated without writing too much red tape, by invisibly expanding to these famous STL declare iterator with the unnecessary long declaration, iterate between begin and end constructs:

    range-based for: 
     Automatically recognizes arrays.
     Recognizes containers that have .begin() and .end().
     Uses argument-dependent lookup begin() and end() for anything else

[ Parent | on HN ]

Re:Rust for C++ programmers – part 2: control flow by masklinn on Sunday April 20, 2014 @04:09AM (#7616215)

> Why all.iter().enumerate() and not just all.enumerate() ?

enumerate is a method of the Iterator trait, so you need an iterator. This way it can have a truckload of reusable methods without polluting every collection's namespace I guess, and still things work for collections with multiple iterators (just ask for the right one).

The iteration method does not have to be called ``iter`` I'd think (e.g. a tree structure might provide both a depth-first and a breadth-first iterator, none of which would be accessed via `iter`?)

[ Parent | on HN ]

Re:Rust for C++ programmers – part 2: control flow by acqq on Sunday April 20, 2014 @05:52AM (#7616366)

I'd do:

    for x in all     does .iter()
    for (x,y) in all.enumerate()   does .iter.enumerate()

And were there's no one iter() like trees, only by them it would have to be specified, as they wouldn't have iter():

    for x in all.depthfirstiter()
    for (x,y) in all.depthfirstiter().enumerate()

95% of times 5% percent of the constructs are used, why not making them pleasant?

[ Parent | on HN ]

Re:Rust for C++ programmers – part 2: control flow by masklinn on Sunday April 20, 2014 @06:42AM (#7616432)

> I'd do: for x in all does .iter()

See pcwalton's answer in an other subthread, an Iterable trait (which for would use instead of Iterator) was tried and didn't work out previously, but it's not shelved.

> for (x,y) in all.enumerate() does .iter.enumerate()

That makes literally no sense. What if enumerate() is the thing returning an iterable because reasons? Now it calls enumerate() on the wrong object, or blows up because there's no .iter in the first place.

You could have 30 methods on the Iterable trait (or directly on your vector) which would just delegate to the corresponding Iterator. Not sure there's that much value in it.

> for x in all.depthfirstiter()

Except according to your previous declaration that would result in a call to `all.iter.depthfirstiter()`. Or the compiler has to go magic things around, traverse the chain until it gets the first (or last? Or all of them? How do you pick which one's right?) Iterable, an inject an iter() calls in it…

[ Parent | on HN ]

Re:Rust for C++ programmers – part 2: control flow by pcwalton on Sunday April 20, 2014 @05:24PM (#7618537)

Yes, and in fact there are multiple kinds of iterators even for arrays. ".mut_iter()" and ".move_iter()" are very common.

[ Parent | on HN ]

Re:Rust for C++ programmers – part 2: control flow by pcwalton on Sunday April 20, 2014 @03:58AM (#7616190)

It's simpler to have iterables and iterators be different, and to not overload "for" in potentially confusing ways.

[ Parent | on HN ]