[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