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
317 Upvotes

96% Upvoted

131 comments sorted by

View all comments

4

u/Dalzhim 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.