3 ms·

A while loop is not semantic support for incrementing a number on each loop. It is semantic support for checking a condition on each loop. You can increment a

A while loop is not semantic support for incrementing a number on each loop. It is semantic support for checking a condition on each loop. You can increment a number yourself, but at that point you're doing something where there is significantly better language support for just using iterators. You may as well claim Rust has semantic support for, idk, bubblesort, because you can write bubblesort with it.

throwaway17_17 4y ago
As I said in my edit, the Rust docs explicitly call out the for..in construct as syntactic sugar over a loop which contains an iterator in the body, i.e. 'or-in-loops, or to be more precise, iterator loops, are a simple syntactic sugar over a common practice within Rust, which is to loop over anything that implements IntoIterator until the iterator returned by .into_iter() returns None (or the loop body uses break).' [1] In fact that same page gives the expanded code on it. It directly expands to code using the iterator's .next() method on each go through the loop. So, I think since the difference between the iterator semantics, as defined and describe by the Rust documentation, and using an index variable and incrementing that variable on each loop are not different enough for your exaggerated claim regarding 'semantic support'. But, I'm not trying to convince you to not use iterators or that iterators are not useful in some projects. I don't particularly care what other developers decide are the correct standards for their projects. My initial comment for this sub-thread was just trying to point out that I tend to view a language's semantics at the base level, where iterators are programmer implemented features defined for specific types, and that there is a definite difference between using iterators and using a loop with an index variable for container access. I don't think I was wrong to make that observation, and the Rust docs seem to support that difference. That's all I was getting at. [1] - https://doc.rust-lang.org/std/keyword.for.html https://doc.rust-lang.org/std/keyword.for.html
- solar-ice 4y ago
  Using the iterator's .next() method in a loop - or the built-in expression for doing so - avoids maintaining an integer counter and indexing. It is simply not semantically the same thing, and you cannot approximate what iterators get you with your counting loop in safe Rust code. The difference in semantics is why one enables you to avoid overflow checks and the other does not, given the semantics of Rust which don't allow skipping those overflow checks in safe code. At a "base level", every language is exactly equivalent - they are all approximations of a turing machine - so I really don't get that argument unless you are trying to argue that every language is really just C in disguise.

throwaway17_17 4y ago

As I said in my edit, the Rust docs explicitly call out the for..in construct as syntactic sugar over a loop which contains an iterator in the body, i.e. 'or-in-loops, or to be more precise, iterator loops, are a simple syntactic sugar over a common practice within Rust, which is to loop over anything that implements IntoIterator until the iterator returned by .into_iter() returns None (or the loop body uses break).' [1] In fact that same page gives the expanded code on it. It directly expands to code using the iterator's .next() method on each go through the loop. So, I think since the difference between the iterator semantics, as defined and describe by the Rust documentation, and using an index variable and incrementing that variable on each loop are not different enough for your exaggerated claim regarding 'semantic support'. But, I'm not trying to convince you to not use iterators or that iterators are not useful in some projects. I don't particularly care what other developers decide are the correct standards for their projects. My initial comment for this sub-thread was just trying to point out that I tend to view a language's semantics at the base level, where iterators are programmer implemented features defined for specific types, and that there is a definite difference between using iterators and using a loop with an index variable for container access. I don't think I was wrong to make that observation, and the Rust docs seem to support that difference. That's all I was getting at. [1] - https://doc.rust-lang.org/std/keyword.for.html https://doc.rust-lang.org/std/keyword.for.html

solar-ice 4y ago
Using the iterator's .next() method in a loop - or the built-in expression for doing so - avoids maintaining an integer counter and indexing. It is simply not semantically the same thing, and you cannot approximate what iterators get you with your counting loop in safe Rust code. The difference in semantics is why one enables you to avoid overflow checks and the other does not, given the semantics of Rust which don't allow skipping those overflow checks in safe code. At a "base level", every language is exactly equivalent - they are all approximations of a turing machine - so I really don't get that argument unless you are trying to argue that every language is really just C in disguise.