C++ Committee don’t want to fix range-based for loop in C++23 (broken for 10yrs) | Hacker News Reader

C++ Committee don’t want to fix range-based for loop in C++23 (broken for 10yrs)

twitter.com

35 pointspansa210 comments

Rust sidesteps issues like this entirely through its Editions. Code from different editions can all each other, but editions can introduce breaking changes.

For example, in Rust 2018 and earlier calling arr.into_iter() on an array type would result in an iterator over references of elements of arr (which is the expected result of .iter(), but not .into_iter()). In Rust 2021 this is fixed and arr.into_iter() will take ownership of the array and return an iterator over the values themselves. But old crates that are specified to compile using Rust 2018 will still work, and you can still call them from Rust 2021 without problems.

If the C++ committee ever wants to fix its language it must introduce such backwards-incompatible changes. With the advent of modules this should be possible, you could compile each module using different editions yet still call each other.

That is great to hear. Every language should have a way to introduce "breaking changes" without breaking old code.

Without this, evolution of a language is severely limited.

Inversely, 10 years of software built around a software bug. I'm not sure why I'm seeing so many Tweets being pushed to the top of HN?

Why not just link to the actual presentation and not the arguing hivemind that is Twitter?

http://josuttis.de/cpp/210929_rangebasedfor_p2012r2.pdf

Thanks, that pdf was informative. I wonder if the proposed fix could introduce memory leaks in old code.

>Why not just link to the actual presentation and not the arguing hivemind that is Twitter?

Can't speak for the submitter but many times for technical topics, the replies add more context.

In this particular case, the replies didn't have any arguing and there was also a more detailed pdf with more extensive code samples: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p201...

... was from: https://twitter.com/NicoJosuttis/status/1443453792805064706

It's only a matter of time before the "engaging" arguments are promoted to the top of a twitter feed. Maybe for extremely low traffic posts, but what I see from the top is a snarky comment from Nicolai which essentially is relaying through "yet another" segue of <insert relatable quote> along the lines of "this is stupid, they're stupid, why is this still a stupid problem to have". To his own post.

The following comment about Gasper talks about how it was the approach that was incorrect, not that it shouldn't be fixed. The following response is just defending that "things must be done if asked otherwise who will do the asking" concern trolling.

Below that is unrelated tweets. I'm not about to go and click through a bunch of responses and more replies searching for the discussion. Hence why I think Twitter is a terrible platform to link to.

Twitter is just an engagement platform which feeds off arguments and bickering between people using snarky comments so people feel clever. Getting hearts/likes so that you know x number of people on the internet approve of your message.

Maybe they should just add a compiler flag and split off the behaviour, so by default the bug isn't present, but it's available for those who need it?

  --use-old-behaviour-range-based-for-loop

Are there already similar flags for other bugs in place?

In the general case, the C++ compiler always needs to know according to which C++ standard the code should be interpreted, so any code compiled as C++14 code should for example use the old behavior. More specifically, some compilers such as Microsoft's compiler support some their old bugs through specific flags (e.g. permissive mode in MSVC).

Thanks. Makes sense. You are right that that's basically the reason why the standard level is such an important thing to specify while compiling.

Reply on news.ycombinator.com