On Fri, 5 Jul 2019, Martok wrote:
Am 05.07.2019 um 02:52 schrieb Michael Van Canneyt:
With this sentence you forbid storing or communicating enumerated values in any way:
file, database, over network. It can be used only in a computer program and never
leave the context of the running program under any form. Because as soon as
it is somehow communicated, there is a chance it becomes invalid in return
communication.
This is the conclusion from Jonas' arguments, which he explicitly confirmed when
we had the discussion two+ years ago.
You're also missing another important type of 'communication': calling non-FPC
APIs or even just FPC libraries of possibly different version (see: Run-Time
Packages!)
APIs falls under 'communicating'. Database is an API. Library is an API,
REST is an API: you communicate the value to a system not under your
control.
Anything that even looks like a subrange cannot be used for these interfaces.
Yes, if you adhere to a strict view.
But IMO such a strict stance is untenable: you cannot ensure correct values
in all cases even within the confines of the language (as demonstrated before).
So, in my book, an intrinsic to check for a correct value in the places where an
invalid value can enter the system is a welcome language feature.
Put another way:
If the programmer is responsible (correctly so) for ensuring correct values,
then I think the language must give him the tools to fulfill his
responsability in a convenient manner. Hence the need for an intrinsic.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
