[fpc-devel] [Suggestion] Enumeration range-check intrinsic

J. Gareth Moreton gareth at moreton-family.com
Wed Jul 3 03:15:11 CEST 2019


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.

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 /specific/ invalid values, then 
they should add them as new entries in the enumeration.

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?

Gareth aka. Kit



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190703/ed80fb14/attachment-0001.html>


More information about the fpc-devel mailing list