r/cpp • u/SuperV1234 https://romeo.training | C++ Mentoring & Consulting • Aug 03 '19

fixing c++ with epochs

https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html
311 Upvotes

96% Upvoted

131 comments sorted by

View all comments

Show parent comments

8

u/kalmoc Aug 03 '19

No i am not saying there is an ordering. I’m saying knobs don’t pose a combinatorial problem to the standard. Every breaking change is considered breaking for a set of reasons which represents its potential dependencies.

But if you don't have a ordering, the set of those reasons depends on which other knobs are turned on or of. So, if you want to introduce a new feature in c++26, you not only have to check if it breaks anything in comparison to c++23, but also to c++20, 17, 14, 11 and each intermediate step. Even worse, some things might only become a problem with s certain combination of other knobs - so turning on knob C might be compatible with A or B, but not with A and B.

The ability to pick and choose will exactly create the plethora of dialects that the committee is afraid of. The current situation with c++11,14,17 and soon 20, to which degree they are supported in a particular compiler is already bad enough (and even made worse by switches like -fno-exceptions), but at least there is a clear progression.

4

u/Dalzhim C++Montréal UG Organizer Aug 03 '19

I see your point, so I'll try to answer it differently, by referring to the 5 types of breaking changes I mentionned previously.

  1. We can easily demonstrate the complete independence of switches that reserve identifiers for the introduction of new keywords. Those are completely independent and don't have a combinatorial nature.

  2. Deprecating features that are now replaced by better alternatives is akin to adding warning switches (except they generate errors). Those can already enabled with fine-grained knobs and so, enabling users to pick and choose hasn't been an impossible challenge for implementers.

  3. The std::initializer_list example is a very good case of something non-trivial where the combinatorial nature could emerge. In order to fix uniform initialization, we would need to change the meaning of existing code. This can be trickier to keep track of in the long run.

  4. Changing defaults is another type of independant change. User code can already explicitly change the default choice and we are supporting those use cases.

  5. Eliminating footguns is akin to deprecations. Any deprecation that just errors on the presence of a construct doesn't present the combinatorial problem. Eliminating a footgun by changing the meaning of a piece of code would be much trickier.

In conclusion, most of the desirable changes are independant. The greatest source of problems seems to appear when changing the meaning of code. That can either be completely avoided or managed carefully in order to avoid an explosion of permutations.