<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 15.07.2017 21:39, Jonas Maebe wrote:<br>
</div>
<blockquote type="cite"
cite="mid:92505d8d-c56b-a0d7-9b1b-44d953c32b41@freepascal.org">On
15/07/17 21:33, <a class="moz-txt-link-abbreviated" href="mailto:lazarus@kluug.net">lazarus@kluug.net</a> wrote:
<br>
<blockquote type="cite">Am Sa., Jul. 15, 2017 21:07 schrieb Jonas
Maebe <a class="moz-txt-link-rfc2396E" href="mailto:jonas@freepascal.org"><jonas@freepascal.org></a>:
<br>
<br>
I have said from the start that it is possible to store
invalid values
<br>
in variables through the use of a.o. pointers (which is what
the class
<br>
zeroing does), explicit typecasts and assembly.
<br>
<br>
In this case you must not restrict us to work with invalid
values in a deterministic way.
<br>
</blockquote>
<br>
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.
<br>
<br>
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.</blockquote>
<br>
The problem is that you yourself force us to the mixture that "is
the worst of both worlds".<br>
<br>
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.<br>
<br>
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!<br>
<br>
Don't you understand the difference between compiler-point-of-view
and the programmer-point-of-view?<br>
<br>
Compiler layer:<br>
- stores invalid enumeration values -> it cannot assume there are
no invalid values<br>
<br>
Programmer layer (two options - his decision):<br>
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.<br>
2.) he doesn't do manual range checking -> he cannot assume there
are no invalid values.<br>
<br>
Again, you have two options:<br>
<br>
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).<br>
<br>
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.<br>
<br>
From my knowledge, the (1) option is utopia in a low-level languages
along with Pascal.<br>
<br>
For reference GNU-C:
<a class="moz-txt-link-freetext" href="https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.pdf">https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.pdf</a> page 11:<br>
<b>"An enumeration is a custom data type used for storing constant
integer values and referring
to them by names."</b><b><br>
</b><br>
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).<br>
<br>
Ondrej<br>
</body>
</html>