What `for x in y` hides from you – From Scratch Code

To be fair, when I started learning CS, the `for x in y` syntax was cryptic to me because I was unfamiliar with concepts such as iterators & generators. `for(int i=0; i<len(y); i++)` made way more sense since there is no hidden logic (besides additions as you highlighted in your comment, but which I think is easier to have a grasp of). So I really wish I had read this article when I started my CS journey a couple of years ago.

In the author's mind, it's unexpected/amazing that 'for' can iterate over many types. But it's NOT unexpected/amazing that 'iter' can iterate over many types. I have no idea why.

It's not like 'for' is limited to counting in other languages. The grand-daddy in c does something until some condition is false, and that thing can equally be incrementing/decrementing a number or invoking some function. That's what a loop does in any case, it compiles down to a conditional jump (JNE/JE..)

Maybe his reason for astonishment is obscured by over-use of an LLM to 'enhance' the text.

It would be very surprising for somebody without a formal software development background and years of experience.

Looking back at 2015 when Python 2 was still supported, there was a lot of confusion for why Python 2 would create a tuple while Python 3 created a generator for the following statement:

  foo = (x for x in [10, 20, 30])

The blog post is trying to help fill in a gap of knowledge for anyone trying to understand more of what goes on behind the curtains.

But it's not a Python thing. Rust is noted below, and there's also C++.

  std::container<T> container;

  for (std::container<T>::iterator i = container.begin(); i != container.end(); ++i) { ...} 

  auto iter = container.begin(); while (iter != container.end()) { ...; ++iter; }

  for (auto const & t : container) { ... }

Very few people who use Python realize the loop is not just looking into the values but asking the values to produce an iterator. It's only when they outgrow this early stage that they are ready to understand how to make a finite iterator themselves.

Which is funny, because whenever I encounter a language for which `for` *doesn't* work this way it feels antiquated. I do however wish another keyword was used in many cases, becuase `for` in C and Go is so much different then `for` in Rust or Python. I think the higher-level case (Rust and Python) should really use a word like `foreach` or maybe something compeletely different like `itr`, although I get that they want to "look" more like C

Is "hiding" in the sense that you just need to have read the docs or know how the language works at a pretty basic level really a problem, or even a negative? I would certainly say that the readability and clarity on the form of loop being used is a bigger win, either way.

It's true that they're just sugar but Rust does explain how the for-in loop de-sugars and you've over-simplified considerably. Your syntax also doesn't quite work.

The value is in idiom, turning everything into loop expressions (The "while" keyword is also just sugar, Rust's only fundamental loop is named loop) makes it harder to discern what's actually going on.

If you want to clone the iterator in some cases rather than consuming it, that should look different so that reviewers will see what you're up to.

It should be `v.into_iter()`, and that distinction matters because of ownership / move semantics.

It just so happens that for most collections, `IntoIter` is also defined for references to them, which typically gives you the same behavior that `.iter()` would give.

In addition to the points that sibling comments have made about how you're not quite right with the exact semantics of for loops (which also take ownership via `into_iter` and therefore are a bit different from `while let`), it's worth pointing out that if you peek a bit further in to MIR, all loops in Rust just desugar into the `loop` keyword with manual breaking, including `while`. It's not really clear to me why for loops in particular bother you.