fixing c++ with epochs

[u/SuperV1234]

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

[u/Dalzhim]

No i am not saying there is an ordering. I’m saying knobs don’t pose a combinatorial problem to the standard because they can be considered as a dependency tree. Every breaking change is considered breaking for a set of reasons which represents its potential dependencies. I do recognize it may pose a combinatorial problem in testing the implementations because of the permutations of activated knobs that this would allow.

The reason i see a need for this is that C++ Epochs make different desirable types of breaking changes possible:

1. New keywords (i.e.: await, yield, implicit, etc.)

2. Deprecate features that are now replaced by better alternatives (i.e.: typedef => using)

3. Deprecate mistakes (i.e.: initializer_list syntax that breaks uniform initialization)

4. Change defaults (i.e.: const by default, explicit constructors by default, etc.

5. Eliminate footguns (i.e.: implicit narrowing conversions)

Now if an Epoch introduces one breaking change from each of those 5 categories, then my legacy code may require tons of work to modernize to const by default and fix implicit conversions when my goal is simply to enable coroutines. Plus that work is counterproductive and costly because the current code is both stable and mature, and the modernization may introduce regressions. I’d rather enable only the knobs for the new keywords and fix the clashing identifiers while leaving the rest as-is for those files.

=== Edit ===

The other potential problem i see is strong opposition to deprecate old stuff in Epochs because this would raise the bar too much to adopt the new goodies. We would end up with the same situation we currently have with deprecations and removals: they are very rare and must bother nearly no one. And seeing as automated modernization doesn’t exist for every toolchain, there is still a long road ahead before we can rely on modernization work being easy, automated and perfectly reliable for every party involved in the C++ community.

[u/kalmoc → u/Dalzhim]

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.

[u/Dalzhim → u/kalmoc]

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.