On 15.07.2017 21:39, Jonas Maebe wrote:
On 15/07/17 21:33, laza...@kluug.net wrote:
Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe <jo...@freepascal.org>:
I have said from the start that it is possible to store invalid
values
in variables through the use of a.o. pointers (which is what the
class
zeroing does), explicit typecasts and assembly.
In this case you must not restrict us to work with invalid values in
a deterministic way.
You can if you always use explicit typecasts to different types and
access everything through pointers and assembly. But then the question
is why you want to use a restrictive type in the first place.
Either you declare a type as only holding a limited set of data when
valid and assume it behaves as such, or you don't. A mixture is the
worst of both worlds: no type safety and unexpected behaviour when
something else assumes the type declaration actually means what is
written.
The problem is that you yourself force us to the mixture that "is the
worst of both worlds".
On the one hand you say that the compiler can generate invalid values
and on the other hand you say that the compiler can assume the enum
holds only valid values. For now, there is absolutely no range checking
and type safety for enums - so you can't use it as an argument.
You say "you declare a type as only holding a limited set of data when
valid and assume it behaves as such" - yes I declare it as such but the
compiler itself stores invalid data there. The compiler cannot assume
the data holds only valid values if it happily stores invalid values itself!
Don't you understand the difference between compiler-point-of-view and
the programmer-point-of-view?
Compiler layer:
- stores invalid enumeration values -> it cannot assume there are no
invalid values
Programmer layer (two options - his decision):
1.) he checks all values in the enums himself and does range checking
manually -> he and only he (not the compiler) can assume there are no
invalid values.
2.) he doesn't do manual range checking -> he cannot assume there are no
invalid values.
Again, you have two options:
1.) Give us full type safe enums with full range checking that CANNOT
hold invalid values after any kind of operation (pointer, typecast,
assembler ...). Then I am fully with you: keep the case optimization as
it is (and introduce more optimizations).
2.) Keep the enums as they are (not type safe) and don't do any
optimizations on type safety assumptions on the compiler level. Because
there is no type safety.
From my knowledge, the (1) option is utopia in a low-level languages
along with Pascal.
For reference GNU-C:
https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.pdf page 11:
*"An enumeration is a custom data type used for storing constant integer
values and referring to them by names."**
*
Pascal stores the enumeration values the same as C. It doesn't make
sense to handle enums like you want them (which would make sense in
high-level programming languages that Pascal is not).
Ondrej
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
