Hacker News Reader

Comment by 90s_dev | Hacker News Reader

> Don't misunderstand me - I love using foreach in other languages; the added syntax better expresses your intent, reducing logic errors. It did jump out at me as "this isn't C" though.

Because it's not. The whole point of C is that you know exactly what's going on and it's relatively clear in the code itself. C++ hides logic in abstractions for the sake of convenience. This is a C++ thing. How does it know how to iterate? Is it moving pointers or indexing them or what? Not only is it hiding logic but it also prevents me from modifying the logic. I could easily change a C for loop to use i += 2 instead of i++ if I wanted, that's the beauty of it. With this, I have to read some docs first to see how their abstraction works, and then hope it allows me to modify how it's used to how I need.

View on HN

> The whole point of C is that you know exactly what's going on and it's relatively clear in the code itself.

Given the widespread undefined behavior and the ways that compilers aggressively rely on that to reorganize and optimize your code, that hasn't been the case for many many years.

Sure, if you're using dmr's compiler on a PDP-11, then C is a pretty transparent layer over assembly, which is itself a fairly thin layer over the CPU. But today, C is an ambiguous high level communication language for a highly optimizing compiler which in turn produces output consumed by deep pipeline CPUs that freely reschedule the generated instructions.

Rescheduling instructions is not relevant, is it? Are there architectures which change the semantics of the instructions by changing execution order?

> Rescheduling instructions is not relevant, is it?

I guess it probably depends on why a user might want to think of C as low level. The user visible semantics shouldn't change, I hope, but the performance might.

> I could easily change a C for loop to use i += 2 instead of i++ if I wanted, that's the beauty of it.

If you're not doing something for each element of a collection, you should not be using a `foreach` loop. In exchange for not exposing the implementation, you immediately know the behavior. You also don't have to worry about checking the rest of the loop body for later mutations.

It uses operator overloading of [] &[] and "len" to create a straight for loop. Normal C for loops are there of course.

I just skimmed the C3 spec[1] on foreach and foreach_r, and I'm still confused as to how to move elements by anything other than 1, if it's even possible.

[1] https://c3-lang.org/implementation-details/specification/#fo...

It isn't possible. Use `for` instead. `foreach` isn't trying to be a one-stop-shop, but rather help the common case of looping over an array or list. Because it handles caching the length and such it's more efficient than a casually written `for` loop. This is the 90% solution to iteration.

Ah that makes sense, as long as the length doesn't change during iteration, which like you said is the 90% case. As long as I also can use for(), then that's fine.

Yeah, you will need to pry `for` from my dead cold hands.

Just curious - in what situations would you want to use `foreach` (with the intent to iterate over a sequence), but use `i += 2` instead of `i++`? I can only think of a situation where I want to group elements by pairs, but then I'm explicitly not doing a "for each", and would prefer to explicitly use a regular `for`.

Vectorization unrolling?

In that case I advice using actual C3 vectors. They are a built in type that will use simd (or similar) under the hood if the compilation target supports it.

This is a completely valid and reasonable argument; I don't understand why people are downvoting it.

Votes on HN are fairly random.

So we should get rid of them, especially the downvotes.

Because it seems fairly obvious you can use a standard `for` if you need more control over the iteration.

The argument is still reasonable. The OP didn't claim that there is no "for" loop, but that the "foreach" is a high-level construct which is not intuitively comprehensible and thus doesn't fit to the C3 language design.

Reply on news.ycombinator.com