Pierre Muller <pie...@freepascal.org> schrieb am Fr., 5. Juli 2019, 17:51:
> > > Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit : > > > > 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? > > My answer would be: > > in FPC modes, simply generate a CompileTimeError as above, > > in Delphi mode, as Delphi states stat the holes are also valid values of > the range, > then indeed, pred() and succ() can do the simple thing they do when there > are no holes, > and 'is' or 'as' should then also do the same, i.e. only check that the > value is inside > the range defined by the lowest and highest values! > > But on course this means that in Delphi mode, > even after validating with 'is' you could still have a valid enum value > that has no > name, i.e. that is in one of those black holes ... > > I don't need to tell you that I do have a preference for the ordinary > Free Pascal way! > I think Gareth meant his question for enums without holes ;) Regards, Sven >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel