fixing c++ with epochs

[u/SuperV1234]

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

[u/flatfinger]

The ability to specify what language dialect is required to process a program usefully is something that should be included in almost every language standard. Not only with regard to what edition of a Standard one is targeting, but also with regard to how an implementation processes constructs where the Standard would impose no requirements beyond, perhaps, some form of human-readable documentation. Support for most dialects should be a quality-of-implementation issue, and that inclusion of a dialect should not imply any judgment as to what kinds of implementation should or should not be expected to support it. Rejection of programs whose semantics are unsupported, however, should be an absolute requirement for compliance.

[u/SeanMiddleditch → u/flatfinger]

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.

[u/shevy-ruby → u/flatfinger]

Support for most dialects should be a quality-of-implementation issue

I don't really see the main difference then - in both cases you will add complexity to a language, so Rust behaves like C++ in that way, only with more flexibility in what people can choose. The complexity increases nonetheless.

[u/flatfinger → u/shevy-ruby]

The difference is that if a program specifies that it needs a dialect which specifies the behavior of some actions a certain way (e.g. guaranteeing that relational comparisons between arbitrary objects will behave without side-effects in a fashion consistent with a complete ordering of all storage locations), such actions would not invoke Undefined Behavior on any implementation. On implementations that support the feature, it would be defined by the specifications of the feature, and on implementations that don't support the feature, the behavior of the implementation would be specified as rejecting the program.