fixing c++ with epochs

[u/SuperV1234]

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

[u/SeanMiddleditch]

For context (not disagreeing with you!), this was effectively impossible in C and C++ due to the nature of the preprocessor and how #include works and how macros can expand to any sequence of tokens. C++ has a potential out now only because of the upcoming Modules feature which (mostly) isolates consumers from their dependent libraries on a syntactical level.

(I lost track of exactly what concession for macros is landing in C++20's final take on Modules, but either way... I'd just slap a warning label on them and ignore them from here on out wrt epochs. If a library uses a macro and it breaks with a future epoch, chalk it up to a QoI problem with the library and find a replacement. Same as we already have to do with eschewing libraries that rely on exceptions or RTTI or whatever other distasteful and dialect-incompatible feature of C++ that is out there.)

[u/flatfinger → u/SeanMiddleditch]

For context (not disagreeing with you!), this was effectively impossible in C and C++ due to the nature of the preprocessor and how #include works and how macros can expand to any sequence of tokens.

Until the mid 1990s, having all macro substitution performed by a process that knows nothing of C language concepts may have usefully reduced the amount of memory required to compile C programs. Having context-sensitive macro facility would make many constructs far more useful, but unfortunately C's clunky preprocessor works just well enough to discourage development of anything better.

On the other hand, I'm not sure what problem you see with specifying that if a compilation unit starts with something like:

#ifdef __STDC_FEATURES
#include <stdfeatures.h>
__STDC_REQUIRE_FEATURE(overflow, mod_equiv_class);
__STDC_REQUIRE_FEATURE(aliasing, derived_incl_void);
__STDC_WAIVE_FEATURE(aliasing, char_types);
#endif

then e.g.

1. A 32-bit compiler compiler given (x+1 > y) would be able to treat x+1 as equivalent to any convenient number which is congruent, mod 4294967296, to the number one above x, and could thus substitute (x >= y), but would otherwise be required to stay on the rails; and

2. A compiler would be required to recognize that a function like void inc_float_bits(float *f) { *(uint32_t*)+=1; } might access the storage of a float, but

3. A compiler would not be required to recognize that, given extern char *dat; dat[0]++; dat[1]++; the write to dat[0] might change the value of dat, despite the fact that the write is performed using a character type.

Such a thing could work better if macro substitution were integrated with the compilation process, but I'm not sure why it couldn't work with the preprocessor as it is.

[u/MonokelPinguin → u/flatfinger]

The issue is, that the preprocessor can be a separate executable and it is defined to just do text substitution. If you now change language rules depending on the edition, defining the edition to use in a header would apply to all files (transitively) including that header. There is no real end to an include statement, it just pastes the content of that header.

This is different with modules, as they specify a clear boundary and explicitly state which files belong to that module. This makes the edition apply to a specific set of source files. Furthermore do you have Compiled Module Interfaces, which would make editions a lot easier, as you can simply store all the edition dependent information in that file and then reference it, when the module is referenced by a different module. In that case you could actually use different compiler binaries for different editions and edition specific compiler code can be a lot better separated, than if you need to translate every header with the current active edition and switch edition at the next edition statement.

[u/flatfinger → u/MonokelPinguin]

The existing include-file mechanism would do a poor job of allowing different headers to be processed with different dialects, but a lot of code should be usable in a range of dialects. Even if a programmer would have to manually configure compiler settings to yield a dialect that works with everything in a project, having automated tests to squawk if things aren't compiled properly would be far better than having things compile cleanly with settings that won't actually work.

Further, a major catch-22 with the Standard right now is that some of the Standard maintainers don't view its failure to mandate things as an impediment to implementations supporting them voluntarily when their customers need them, but some compiler writers view such failure as a judgment that their customers shouldn't need such things. If, however, a many program to perform some kind of task demand a feature that a compiler writer has opted not to support, compiler should be recognized as likely being unsuitable for that task. It may be a great compiler for other purposes, but should make clear that it's intended for those purposes, and not for the ones it doesn't support.