[fpc-devel] Dangerous optimization in CASE..OF

[DaWorm]

Academically that may be true, but in the real world that code wouldn't be
unreachable.  I write code that deals with communication protocols all the
time.  I can't control what the other side sends.  I have two choices.
Write a lot of code to validate each and every element is within the proper
range, or let the handler for each element, that I have to write anyway,
deal with the unexpected values. This is something that comes up a lot
dealing with backwards compatibility where one end of a system is upgraded
and the other is not (think like mobile apps where you cannot force all
phones to switch to the new version simultaneously).  A new element will be
added to one side that the other doesn't know about.  The older code should
handle this gracefully, and the else of a case is certainly the most
convenient place to do this from the programmer's perspective (or at least
mine anyway).

It can be worked around by casting all parts of the case to integer, but
that leads to ugly code.

I'd write up an example but I'm writing from my phone.

Jeff

On Jul 16, 2017 10:49 AM, "Jonas Maebe" <jonas at freepascal.org> wrote:

> On 16/07/17 16:34, DaWorm wrote:
>
>> If the programmer builds a case statement on an enum, that includes all
>> of the possible enum values, and also includes an else clause, to me it
>> seems the programmer is implicitly telling the compiler that there is the
>> possibility of illegal values stored in the enum.
>>
>
> Writing unreachable code never has constituted implicitly telling a
> compiler anything in any programming language. At best, you will get a
> warning from the compiler that the code is unreachable.
>
> You don't want a compiler to start second-guessing what you might have
> meant when you wrote something. Everything must be 100% unambiguous.
>
>
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20170716/1d93c511/attachment.html>