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.
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).
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.
11 comments
[ 0.20 ms ] story [ 41.0 ms ] threadWhy not just link to the actual presentation and not the arguing hivemind that is Twitter?
http://josuttis.de/cpp/210929_rangebasedfor_p2012r2.pdf
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
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.
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.
Without this, evolution of a language is severely limited.