<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>To clarify my stance on all of this... when enumerated types are
      entirely internal within a program, then there is indeed no need
      for constant range checks like with case blocks because the value
      is almost always guaranteed to be valid unless you do something
      weird like Pointer typecasting, using 'absolute' or manipulating
      the value with assembly language, in which case, all bets are
      definitely off.</p>
    <p>However, when you start interfacing with something external, such
      as a file or a third-party library, then there is a chance that
      you will get an invalid value through no fault of your own, but
      you still need to be able to handle it in some way, because
      crashing with an access violation is wholly unacceptable behaviour
      (e.g. a server application that serves many millions of clients,
      or the firmware on a flight computer).  Normal range checks won't
      work because the compiler believes the variable can never take on
      those invalid values and so will optimise them out.  In this case,
      there needs to be an explicit exception to the rule so we can take
      an alternative branch - all that is needed is a result that says
      "this enumeration contains an invalid value" and handle it as
      desired, either via a specific exception being raised (with "as")
      or a Boolean condition (with "is").  There doesn't need to be any
      other kind of range check; if the programmer wants to handle <i>specific</i>
      invalid values, then they should add them as new entries in the
      enumeration.</p>
    <p>I understand the desire and benefits of language purity, but when
      multiple programmers fall foul of a particular feature with no
      clear workaround, then it needs to be evaluated.  Saying "it's not
      a bug, it's a feature" and "invalid data equals undefined
      behaviour" will just frustrate people and potentially cause them
      to switch to an alternative development tool.  If you ask around,
      some people have already done this or have chosen not to adopt FPC
      because of it.  Yes, FPC is not perfect and never will be, but why
      shouldn't we strive for it anyway?</p>
    <p>Gareth aka. Kit<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>