<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>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.</p>
    <p>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.</p>
    <p>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 <b>pure</b> 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.</p>
    <p>Long story short, having a specification with statements like "<i>Case
        blocks must have a valid branch for all possible input values,
        either through branches for individual values and ranges, or via
        an </i><i><b>else</b></i><i> branch.  Not abiding by this
        condition will raise a compiler warning.</i>" and "<i>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.</i>" will go a long way to
      ensure the language stays conformant and tidy, I feel.</p>
    <p>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.<br>
    </p>
    <p>What are your thoughts?</p>
    <p>Gareth aka. Kit</p>
    <p>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.<br>
    </p>
  <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <tr>
        <td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
                <td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a>
                </td>
        </tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>