[fpc-devel] *** GMX Spamverdacht *** Re: Dangerous optimization in CASE..OF

[Thorsten Engler]

"in" is an operator that takes two values, and checks if the first value is in the second. 

"is" is an operator that takes a value and a type, and returns if that value can be treated as being of that type.

"in" is an overloadable operator for ordinal types. It is also already a valid operator for ordinal types. So introducing this could break existing code. 

"is", like "as", is not overloadable, and is currently not a valid operator for ordinal types, so introducing a build in implementation of that operator for ordinal types will not break existing code.

This (recent part of this) thread started with the announcement of having implemented "as" for enum types and continued with looking for a solution to do a TryIntAsEnum.

For classes, you already have the two patterns:

y := x as TSomeClass;

if x is TSomeClass then
  y := TSomeClass(x);

in light of this, it makes perfect sense to follow the same pattern with enums:

y := x as TSomeEnum;

if x is TSomeEnum then
  y := TSomeEnum(x);

Furthermore, enums are simply a specialized type of sub-range ordinals, which are really just a spezialed type of general ordinals.

As such, there is no fundamental reason to restrict these two new build in operators to only enums.

y := x as TSomeEnum;

is equivalent to:

if not (x is TSomeEnum) then
  RangeCheckError;
y := TSomeEnum(x);

and:

x is TSomeEnum 

is equvalent to:

(x >= Ord(Low(TSomeEnum))) and (x <= Ord(High(TSomeEnum)))

Given these transformations, there is no reason to restrict this to enums, because exactly the same transformations work exactly the same with any ordinal type.

Cheers,
Thorsten

> -----Original Message-----
> From: fpc-devel <fpc-devel-bounces at lists.freepascal.org> On Behalf
> Of Ozz Nixon
> Sent: Saturday, 14 April 2018 23:16
> To: FPC developers' list <fpc-devel at lists.freepascal.org>
> Subject: Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous
> optimization in CASE..OF
> 
> following the grammar, I would suggest “in” when trying to do what
> you want, not “is”.
> 
> if a in 3..10 then begin
> 
> to me reads more accurately than
> 
> if a is 3..10 then begin
> 
> is the keyword is implies 1, just like the English language,
> whereas, in and are implies multiple or in this case range.
> 
> > On Apr 14, 2018, at 9:02 AM, Thorsten Engler
> <thorsten.engler at gmx.net> wrote:
> >
> > For objects "is" compares (the type of) the value (not the type
> of the variable) against the specified type. Effectively telling
> you if you can do a hard cast of that value to that type.
> >
> > For ordinals, it compares the value against the specified type.
> Effectively telling you if you can do a hard cast of that value to
> that type.
> >
> > I fail to see the difference?
> >
> >> -----Original Message-----
> >> From: fpc-devel <fpc-devel-bounces at lists.freepascal.org> On
> Behalf Of
> >> Ozz Nixon
> >> Sent: Saturday, 14 April 2018 22:43
> >> To: FPC developers' list <fpc-devel at lists.freepascal.org>
> >> Subject: Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous
> >> optimization in CASE..OF
> >>
> >> I understand the thread, however, in one of the ISO standards
> for
> >> Pascal, the keyword is, is defined for type not value. The
> example I
> >> gave is the only way I can see supporting is on non objects -
> because
> >> we are a typed language. That was my point, not arguing against,
> >> however, sharing a way I could see a value of it. Other than
> that, I
> >> am against...
> >>
> >> Ozz
> >>
> >>> On Apr 14, 2018, at 8:38 AM, Thorsten Engler
> >> <thorsten.engler at gmx.net> wrote:
> >>>
> >>> Eh, Ozz? Did you actually read this thread?
> >>>
> >>> It has nothing to do with the declared type of i. it compares
> the
> >> current value of i against the range of the specified type and
> will
> >> return true if the current value falls inside that range.
> >>>
> >>> 5 is TSubRange -> true
> >>> 2000 is TSubRange -> false
> >>>
> >>> Also:
> >>>
> >>> case i as TSubRange of //exception if i < -5 or i > 5
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: fpc-devel <fpc-devel-bounces at lists.freepascal.org> On
> >> Behalf Of
> >>>> Ozz Nixon
> >>>> Sent: Saturday, 14 April 2018 22:13
> >>>> To: FPC developers' list <fpc-devel at lists.freepascal.org>
> >>>> Subject: *** GMX Spamverdacht *** Re: [fpc-devel] Dangerous
> >>>> optimization in CASE..OF
> >>>>
> >>>> I have to ask why?
> >>>>
> >>>> i is Int64 only, will always be int64 only, so all other
> >> comparisons
> >>>> are always skipped.
> >>>>
> >>>> I could see this, inside a method with an untyped parameter:
> >>>>
> >>>> procedure doSomething(myvar;out success:boolean); Begin  {…
> your if
> >>>> is comparisons …} end;
> >>>>
> >>>> This opens your method to be used for all types for param1.
> >>>>
> >>>> Ozz
> >>>>
> >>>>> On Apr 14, 2018, at 5:51 AM, Thorsten Engler
> >>>> <thorsten.engler at gmx.net> wrote:
> >>>>>
> >>>>> I haven't checked out the changes you made to the compiler,
> so
> >>>> you might have already covered this, but while you are at it,
> >> you
> >>>> might want to just make this work for any ordinal type with a
> >> well-
> >>>> defined upper/lower bound (any type for which High()/Low() can
> >> be
> >>>> evaluated at compile time). So:
> >>>>>
> >>>>> type
> >>>>> TSubRange=-5..5;
> >>>>> TEnum=(One, Two);
> >>>>>
> >>>>> var
> >>>>> i: Int64;
> >>>>>
> >>>>> begin
> >>>>> if i is TSubRange then
> >>>>>  //...
> >>>>> If i is TEnum then
> >>>>>  //...
> >>>>> If i is SmallInt then
> >>>>>  //...
> >>>>>
> >>>>> (same with "as").
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: fpc-devel <fpc-devel-bounces at lists.freepascal.org> On
> >>>> Behalf Of
> >>>>>> Ondrej Pokorny
> >>>>>> Sent: Saturday, 14 April 2018 19:03
> >>>>>> To: fpc-devel at lists.freepascal.org
> >>>>>> Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF
> >>>>>>
> >>>>>> On 14.04.2018 10:39, Thorsten Engler wrote:
> >>>>>>> How about following the same schema as with classes?
> >>>>>>>
> >>>>>>> If 1 is TMyEnum then
> >>>>>>> //use hard cast here
> >>>>>>
> >>>>>> Yes, that is reasonable as well and it will be easier to
> >>>> implement
> >>>>>> than the TryIntToEnum/IntToEnum intrinsics for me.
> >>>>>>
> >>>>>> Ondrej
> >>>>>> _______________________________________________
> >>>>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> >>>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-
> devel
> >>>>>
> >>>>> _______________________________________________
> >>>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> >>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-
> devel
> >>>>
> >>>> _______________________________________________
> >>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> >>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> >>>
> >>> _______________________________________________
> >>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> >>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> >>
> >> _______________________________________________
> >> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> >
> > _______________________________________________
> > fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel