Regarding things to be documented in Delphi: As was established last year, this
aspect of FPCs type system is intended to be a bit more strict than that of the
Hejlsberg languages (*), so I'm not taking anything for granted any more. (Case
in point, while I see it: the very different role of range
"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
On 14.04.2018 15:16, Ozz Nixon wrote:
following the grammar, I would suggest “in” when trying to do what you want,
not “is”.
if a in 3..10 then begin
You can overload the IN operator:
https://www.freepascal.org/docs-html/ref/refse104.html#x213-23500015.6
According to Jonas, this could make
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.
>
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
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 c
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:
c
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 use
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:
t
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
How about following the same schema as with classes?
If 1 is TMyEnum then
//use hard cast here
> -Original Message-
> From: fpc-devel On Behalf
> Of Ondrej Pokorny
> Sent: Saturday, 14 April 2018 18:32
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Dangerous optimizat
On 14.04.2018 10:24, Michael Van Canneyt wrote:
On Sat, 14 Apr 2018, Ondrej Pokorny wrote:
Effectively, you should be able to use:
var
E: TMyEnum;
begin
if TryIntToEnum(1, E) then
instead of
if TryIntToEnum(TMyEnum, 1, E) then
I am all for it, although I think the "as" syntax is more e
On Sat, 14 Apr 2018, Ondrej Pokorny wrote:
On 14.04.2018 9:59, Michael Van Canneyt wrote:
On Sat, 14 Apr 2018, Ondrej Pokorny wrote:
On 02.07.2017 18:49, Jonas Maebe wrote:
I would be in favour of a new intrinsic.
I have to admit that for some usages I would prefer a compiler
intrinsi
On 14.04.2018 9:59, Michael Van Canneyt wrote:
On Sat, 14 Apr 2018, Ondrej Pokorny wrote:
On 02.07.2017 18:49, Jonas Maebe wrote:
I would be in favour of a new intrinsic.
I have to admit that for some usages I would prefer a compiler
intrinsic that returns False instead of raising an exce
On Sat, 14 Apr 2018, Ondrej Pokorny wrote:
On 02.07.2017 18:49, Jonas Maebe wrote:
I would be in favour of a new intrinsic.
I have to admit that for some usages I would prefer a compiler intrinsic
that returns False instead of raising an exception. Something like:
function TryIntToEnum(c
On 02.07.2017 18:49, Jonas Maebe wrote:
I would be in favour of a new intrinsic.
I have to admit that for some usages I would prefer a compiler intrinsic
that returns False instead of raising an exception. Something like:
function TryIntToEnum(const AValue: Integer; var
AEnumValue: T): Bool
16 matches
Mail list logo
