6 ms·

Just FUD while spreading FUD? Are you trying to say release mode doesn't have runtime checks inserted? What I want is a check outside of the loop then every ac

Just FUD while spreading FUD? Are you trying to say release mode doesn't have runtime checks inserted? What I want is a check outside of the loop then every access inside a loop unchecked and fast. Which isn't what rust does. Then it throws your memory away if you did an oops and went out of bounds

pitaj 4y ago
> What I want is a check outside of the loop then every access inside a loop unchecked and fast. Which isn't what rust does. That's exactly what iterators allow.
- throwaway17_17 4y ago
  I think the caveat to this is that iterators are a fundamentally different programming 'construct' than a statement block using an index to access elements of a container and then having that index increase with each loop. I tend to treat iterators as a non-factor when discussing semantics of a language as I will always default to them not being a 'language-level' construct. I am not a fan of iterators in any case, but then again, I don't particularly like any higher level constructs in my 'run-time' code.
  - Arnavion 4y ago
    I'm sure you can understand why "I'm going to ignore this part of the language because it damages my argument" might be convincing to yourself but not to others.
    - throwaway17_17 4y ago
      I’m not sure what argument you see me making. I’m also not ignoring anything. And I am most certainly not trying to convince anyone of anything. In the comment you are responding to I am talking about how I view language constructs and their impact on my view of semantics. I don’t have an argument to make. The closest thing to an argument I am making is that iterators are a different language construct than a basic looping construct. If you disagree that’s fine, like I said, I’m not trying to ‘win’ anything or convince anyone of anything. Edit to refer to sibling comment — As I said in a sibling comment, the iterator loop construct is syntactic sugar and that’s why I was saying it is different from discussing a more basic looping construct.
  - solar-ice 4y ago
    Rust has built-in semantic support for iterators; the compiler knows about the Iterator and IntoIterator traits and has specific syntax (the for expression, also known as the "iterator loop expression") to use them. In fact there is no direct semantic support for the type of loop you are talking about.
    - throwaway17_17 4y ago
      Rust does have a for in construct that is implemented in terms of iterators. However, Rust certainly has a while loop also defined as a part of the language. The docs.rust-Lang also defines a loop construct that is only exited with a break statement. So there is clearly semantic support for a looping construct that just loops over code and can contain an incrementing index variable. I would have to check the intermediate language, but I assume the for in construct is implemented, at the semantic level as an iterator object inside a while or basic loop construct. Edit — I just checked and docs.rust-langexplicitly states that the for in construct is ‘syntactic sugar’ for the common case of looping over a container that implements the iterator trait.
      - solar-ice 4y ago
        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
  - sophacles 4y ago
    Your "run-time" code with iterators vs with a hand made for loop tends to result in the same set of instructions. Often the iterator usage will also enable optimizations that make the loop faster. * https://github.com/mike-barber/rust-zero-cost-abstractions https://github.com/mike-barber/rust-zero-cost-abstractions * https://carette.xyz/posts/zero_cost_abstraction/ https://carette.xyz/posts/zero_cost_abstraction/ * https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractio...
    - throwaway17_17 4y ago
      Once I got through writing this comment I realized it was really long and was not particularly enlightening or insightful, but I decided to go ahead and post it. If you have any opinions on it I'm always to glad to read what other people think about language design/usage and surrounding topics: I don't disagree that the translation may result in roughly similar assembly/bytecode instructions in many languages, and while TFA is Rust-centric and most of the conversation has been too, my issues with iterators are not restricted to Rust. Further, my objection to using them in my own code is not strictly a performance issue (although, I am never in favor of coding and hoping it gets optimized). Inherently, iterators are a more complex concept than a loop (or the tail recursive equivalent). Iterators are an object in and of themselves that are by design more complex than a natural number index, then you still need the actual looping construct. I am aware there are reasons that iterators are preferred and often recommended in some situations. However, the determination to use an iterator based construct in your code is not a universal declaration of fitness, it is only a case-by-case determination weighed against whatever other factors matter to the people writing the code. I also think this applies to the pushing of iterators as an idiomatic construct in a programming language, i.e. whether iterators are idiomatic is a determination that is made by the language designers when weighed against the established goals and priorities of the language as a whole. Regarding the iterator-based code enabling optimizations that make the resulting compiled code faster than a basic while loop: I will admit that there is a possibility for this to occur. However, that is tempered by an educated guess that the enabling of those optimizations only occur because the compiler writers have explicitly coded in a 'hot-path' for iterator constructs into the IR. Also, there is the chance that the compiler writers use the higher level IRs to memoize data about the loop as a whole (based on knowledge of the language's iterator construct) and the presence of that data at later stages of the compiler allow for optimizations to occur, whereas the while loop would not trigger the memoization steps and then could not produce the optimizations. Both of those circumstances are a result of the language designers/compiler writers basing code generation (or IR generation) off of the idioms of the language and the underlying semantic definitions of the language. As an aside, I am not certain Rust's compiler treats iterators the way I described above, but I would be surprised if it was not.
Ygg2 4y ago
No. It doesn't have by default. Adding those is a performance hit. > What I want is a check outside of the loop then every access inside a loop unchecked and fast That's what Iterators give you.

pitaj 4y ago

> What I want is a check outside of the loop then every access inside a loop unchecked and fast. Which isn't what rust does. That's exactly what iterators allow.

throwaway17_17 4y ago
I think the caveat to this is that iterators are a fundamentally different programming 'construct' than a statement block using an index to access elements of a container and then having that index increase with each loop. I tend to treat iterators as a non-factor when discussing semantics of a language as I will always default to them not being a 'language-level' construct. I am not a fan of iterators in any case, but then again, I don't particularly like any higher level constructs in my 'run-time' code.
- Arnavion 4y ago
  I'm sure you can understand why "I'm going to ignore this part of the language because it damages my argument" might be convincing to yourself but not to others.
  - throwaway17_17 4y ago
    I’m not sure what argument you see me making. I’m also not ignoring anything. And I am most certainly not trying to convince anyone of anything. In the comment you are responding to I am talking about how I view language constructs and their impact on my view of semantics. I don’t have an argument to make. The closest thing to an argument I am making is that iterators are a different language construct than a basic looping construct. If you disagree that’s fine, like I said, I’m not trying to ‘win’ anything or convince anyone of anything. Edit to refer to sibling comment — As I said in a sibling comment, the iterator loop construct is syntactic sugar and that’s why I was saying it is different from discussing a more basic looping construct.
- solar-ice 4y ago
  Rust has built-in semantic support for iterators; the compiler knows about the Iterator and IntoIterator traits and has specific syntax (the for expression, also known as the "iterator loop expression") to use them. In fact there is no direct semantic support for the type of loop you are talking about.
  - throwaway17_17 4y ago
    Rust does have a for in construct that is implemented in terms of iterators. However, Rust certainly has a while loop also defined as a part of the language. The docs.rust-Lang also defines a loop construct that is only exited with a break statement. So there is clearly semantic support for a looping construct that just loops over code and can contain an incrementing index variable. I would have to check the intermediate language, but I assume the for in construct is implemented, at the semantic level as an iterator object inside a while or basic loop construct. Edit — I just checked and docs.rust-langexplicitly states that the for in construct is ‘syntactic sugar’ for the common case of looping over a container that implements the iterator trait.
    - solar-ice 4y ago
      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
- sophacles 4y ago
  Your "run-time" code with iterators vs with a hand made for loop tends to result in the same set of instructions. Often the iterator usage will also enable optimizations that make the loop faster. * https://github.com/mike-barber/rust-zero-cost-abstractions https://github.com/mike-barber/rust-zero-cost-abstractions * https://carette.xyz/posts/zero_cost_abstraction/ https://carette.xyz/posts/zero_cost_abstraction/ * https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractio...
  - throwaway17_17 4y ago
    Once I got through writing this comment I realized it was really long and was not particularly enlightening or insightful, but I decided to go ahead and post it. If you have any opinions on it I'm always to glad to read what other people think about language design/usage and surrounding topics: I don't disagree that the translation may result in roughly similar assembly/bytecode instructions in many languages, and while TFA is Rust-centric and most of the conversation has been too, my issues with iterators are not restricted to Rust. Further, my objection to using them in my own code is not strictly a performance issue (although, I am never in favor of coding and hoping it gets optimized). Inherently, iterators are a more complex concept than a loop (or the tail recursive equivalent). Iterators are an object in and of themselves that are by design more complex than a natural number index, then you still need the actual looping construct. I am aware there are reasons that iterators are preferred and often recommended in some situations. However, the determination to use an iterator based construct in your code is not a universal declaration of fitness, it is only a case-by-case determination weighed against whatever other factors matter to the people writing the code. I also think this applies to the pushing of iterators as an idiomatic construct in a programming language, i.e. whether iterators are idiomatic is a determination that is made by the language designers when weighed against the established goals and priorities of the language as a whole. Regarding the iterator-based code enabling optimizations that make the resulting compiled code faster than a basic while loop: I will admit that there is a possibility for this to occur. However, that is tempered by an educated guess that the enabling of those optimizations only occur because the compiler writers have explicitly coded in a 'hot-path' for iterator constructs into the IR. Also, there is the chance that the compiler writers use the higher level IRs to memoize data about the loop as a whole (based on knowledge of the language's iterator construct) and the presence of that data at later stages of the compiler allow for optimizations to occur, whereas the while loop would not trigger the memoization steps and then could not produce the optimizations. Both of those circumstances are a result of the language designers/compiler writers basing code generation (or IR generation) off of the idioms of the language and the underlying semantic definitions of the language. As an aside, I am not certain Rust's compiler treats iterators the way I described above, but I would be surprised if it was not.

Ygg2 4y ago

No. It doesn't have by default. Adding those is a performance hit. > What I want is a check outside of the loop then every access inside a loop unchecked and fast That's what Iterators give you.