| > As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem. In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator. C-style for loops are used for three things: - worse syntax for `for x in y..z` - worse syntax for `for x in iterator` (although only C++ does this to my knowledge) - being Clever, and the resulting code being unreadable There's nothing to 'emulate'. C-style for loops are the ones doing the emulating, of range loops. It's just syntax for a particular kind of loop. There's nothing whatsoever different between a while loop and an infinite loop with a break condition, and there's nothing whatsoever different between a for loop and a while loop with a particular final operation. But a while loop represents a construct that is useful more often than not, because you very frequently do want a break condition, while a for loop does not, because the condition-affecting operation is rarely at the end of the loop. It's precisely what I was talking about - adding it because C has it, and not because it is useful. Show me a use of a for loop that isn't an iterator and isn't a range, and I'll show you something that'd be far more readable as a while loop. Oh, and Rust has conclusively proven that yes, you can in fact optimize ridiculously complicated iterators to tiny loops > As for syntax, where does it say "don't use it"? I really don't understand why people state things without evidence. You're right, I had it confused with a different feature: "The expression {} can be used for all types to act as a zero type. This is not recommended as it is not clear and if a type has a specific zero value shown above, please prefer that." Pretty much the exact same question, though. > * Partial ranges with the _two_ range expressions (a..<b and a..=b) look awful and are inconsistent: `x[..<]` `x[..=]`, `x[..<n]` `x[..=n]`, `x[i..<]` `x[i..=]` > * You effectively only ever want Python/Go like semantics with slicing because Odin is a 0-index language It seems very odd to compare Odin's syntax with syntax that doesn't exist in any language, as proof that Odin's syntax is better. Why would you not compare it with the actual range syntax of a common language? Say, Rust. `x[a..=b]`, `x[a..b]`, `x[a..]`, `x[..a]`, `x[..]`, `for x in a..b`, `for x in a..=b`. I see no awful looking or inconsistent syntax there. The point is that no, there is no semantic difference between the two; a range of values between two endpoints is a universal construct, and iterating it means to scan across it, and slicing with it means to produce all the indices contained within it. And you say 'you effectively only ever want Python/Go like semantics with slicing' as though this wouldn't be true for range loops as well. |