<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Pierre Muller <<a href="mailto:pierre@freepascal.org">pierre@freepascal.org</a>> schrieb am Fr., 5. Juli 2019, 17:51:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit :<br>
> <br>
> On 05/07/2019 15:51, Pierre Muller wrote:<br>
>> Just one point from current compiler implementation:<br>
>><br>
>> in trunk/fpcsrc/compiler/ninl.pas (around line 3180)<br>
>><br>
>>                in_pred_x,<br>
>>                in_succ_x:<br>
>>                  begin<br>
>>                     set_varstate(left,vs_read,[vsf_must_be_valid]);<br>
>>                     resultdef:=left.resultdef;<br>
>>                     if is_ordinal(resultdef) or is_typeparam(resultdef) then<br>
>>                       begin<br>
>>                         if (resultdef.typ=enumdef) and<br>
>>                            (tenumdef(resultdef).has_jumps) and<br>
>>                            not(m_delphi in current_settings.modeswitches) and<br>
>>                            not(nf_internal in flags) then<br>
>>                           CGMessage(type_e_succ_and_pred_enums_with_assign_not_possible);<br>
>>                       end<br>
>><br>
>><br>
>> This means that using pred() or succ() intrinsics on enumerated types with<br>
>> holes will generate a Compile Time Error.<br>
>><br>
>>    To be consistent, I would propose that we also generate<br>
>> a Compile Time Error if 'is' or 'as' keyword is used on such a type,<br>
>> unless there is a code that really check that the value is not in<br>
>> one of the holes ...<br>
>><br>
>> Pierre<br>
> <br>
> That seems fair.  The main problem is what happens if, when allowed, <br>
> Prec or Succ are used on such a type on an element that is adjacent to <br>
> one of these holes.  Should it skip to the first element at the other <br>
> end of the hole or raise an exception? Granted, what happens if you use <br>
> Prec or Succ on the first or last element respectively?<br>
> <br>
> I can theoretically design an algorithm to cover these gaps with Boolean <br>
> conditions for the sake of "is", but it's a little bit complex.<br>
> <br>
> Sorry to bring you in on this particular point, Pierre, but if you call <br>
> "Value is TEnum" and Value is of type TEnum but contains an invalid <br>
> value (due to being read from an external stream, for example), should <br>
> it return True or False?<br>
<br>
  My answer would be:<br>
<br>
in FPC modes, simply generate a CompileTimeError as above,<br>
<br>
in Delphi mode, as Delphi states stat the holes are also valid values of the range,<br>
then indeed, pred() and succ() can do the simple thing they do when there are no holes,<br>
and 'is' or 'as' should then also do the same, i.e. only check that the value is inside<br>
the range defined by the lowest and highest values!<br>
<br>
  But on course this means that in Delphi mode,<br>
even after validating with 'is' you could still have a valid enum value that has no<br>
name, i.e. that is in one of those black holes ...<br>
<br>
  I don't need to tell you that I do have a preference for the ordinary Free Pascal way!<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think Gareth meant his question for enums without holes ;) </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>