So after my argument and the counterarguments regarding the new case block warnings, I'm starting to wonder if a semi-official specification should be written for FPC's dialect of Pascal, much like ISO 7185 for Extended Pascal. While FPC is probably the only tool that will use this dialect, it would be useful as a future reference guide as well as for conformance testing.
It might also aid in third-party documentation and enforcing coding standards so that all developers who use Free Pascal know what to expect from the language. Case in point, I never knew that, strictly speaking, case blocks that didn't cover all possible inputs required an else branch even if it was empty - given the code compiled fine without it and its absence logically indicated that such a branch wasn't required, there was nothing to say that I was in conflict with some Pascal standards and getting an accusation of being a lazy programmer. In this case, I fell back to a paradigm of being concise and straightforward, not adding unnecessary code such as, for example, constructors that do nothing but call the inherited version with no changes to the parameter list.
Back on topic though, as well as leaving no doubt as to how the language behaves, it might also work as a design specification to an extent. For example, I still intend to program in support for pure functions, but beyond the *pure* directive (assuming all functions are pure until proven otherwise will cause too much of a performance penalty on the compiler) and the basic concept of their results being computed at compile time if possible, there isn't much else set in stone like where a pure function can be called (e.g. as part of a constant definition), what happens if the compiler determines that a pure function is actually impure, and what makes a function impure. Having something like this fully decided and agreed upon in a language specification will ensure there are no disagreements with implementation specifics.
Long story short, having a specification with statements like "/Case blocks must have a valid branch for all possible input values, either through branches for individual values and ranges, or via an //*else*//branch. Not abiding by this condition will raise a compiler warning./" and "/An "Unreachable code" warning shall be thrown if a case block contains an else branch but which already covers the entire input domain via other branches./" will go a long way to ensure the language stays conformant and tidy, I feel.
While there is documentation online that can easily explain all of this, I find it's only truly useful if you are looking up details on a specific feature - for example, the standard of expanding intermediate expressions to the CPU word size has caught many programmers off-guard. Having it in a single specification means that the curious can read through it in its entirety to learn of these nuances before falling foul of them.
What are your thoughts?
Gareth aka. Kit
P.S. I'm aware that writing it will be a mammoth task, especially to make it semi-official in its wording. I have done paid proofreading work before so I can ensure that what I write is acceptable English, but it would need many sets of eyes evaluating it.
---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus