On 05/07/2019 15:51, Pierre Muller wrote:
Just one point from current compiler implementation:in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]); resultdef:=left.resultdef; if is_ordinal(resultdef) or is_typeparam(resultdef) then begin if (resultdef.typ=enumdef) and (tenumdef(resultdef).has_jumps) and not(m_delphi in current_settings.modeswitches) and not(nf_internal in flags) then CGMessage(type_e_succ_and_pred_enums_with_assign_not_possible); end This means that using pred() or succ() intrinsics on enumerated types with holes will generate a Compile Time Error. To be consistent, I would propose that we also generate a Compile Time Error if 'is' or 'as' keyword is used on such a type, unless there is a code that really check that the value is not in one of the holes ... Pierre
That seems fair. The main problem is what happens if, when allowed, Prec or Succ are used on such a type on an element that is adjacent to one of these holes. Should it skip to the first element at the other end of the hole or raise an exception? Granted, what happens if you use Prec or Succ on the first or last element respectively?
I can theoretically design an algorithm to cover these gaps with Boolean conditions for the sake of "is", but it's a little bit complex.
Sorry to bring you in on this particular point, Pierre, but if you call "Value is TEnum" and Value is of type TEnum but contains an invalid value (due to being read from an external stream, for example), should it return True or False?
Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
