5 ms·
That's just FUD. Rust inserts bounds check automatically in debug mode, if needed. Second, using iterators makes bounds checking redundant. And random access
by Ygg2 4y ago
That's just FUD. Rust inserts bounds check automatically in debug mode, if needed. Second, using iterators makes bounds checking redundant.
And random access `array[intval]` will always be performance crippled if intval is provided by external system at runtime.
Even if intval is guaranteed to be between 0..<array.length, you need to converted it to that type.
- ArrayBoundCheck 4y agoJust 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
- Ygg2 4y agoNo. 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 agoI 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 agoI'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 agoI’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 agoRust 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 agoRust 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.