Hi,

I would like to implement the "is not" operator in fpc. It was introduced in Delphi 13.

For example:

if Obj is not TStringList then ...

It has the same precedence as "is". Since after "is" there can be only an instance, class, interface, etc, and "not" is an all mode keyword, I'm not aware of any conflicts or ambiguities - aka it cannot break any existing code.

Ok?

Mattias

As far as I can see, it cannot break any existing code. So yes, OK.

Michael.

if Obj is not TStringList then ...

Semantically this would be the same as "not (Obj is TStringList)"? What would be the advantages of this new construct?

Delphi compatibility.

Ondrej

Then I suggest to implement it for Delphi mode only.

Regards,

Adriaan van Os

 far more common for me is: if not (xxx in yyy) then. By the same logic it
should be: if xxx not in yyy then

On Sep 11, 2026 at 2:00:47 PM, Mattias Gaertner via fpc-devel <

Hairy Pixels wrote

far more common for me is: if not (xxx in yyy) then. By the same logic it should be: if xxx not in yyy then

The "not in" operator is in Delphi 13 and it's on my list too.

Mattias

Although I am often unhappy with Embarcaderos syntax choices, the "is not" I like. It looks Pascal, does not bite existing code, is easier to read, and is easy to implement.

So I would like to see it any mode that supports "is".

Mattias

Mattias Gaertner wrote

Although I am often unhappy with Embarcaderos syntax choices, the "is not" I like. It looks Pascal, does not bite existing code, is easier to read, and is easy to implement.

Well: "does not bite existing" is technically incorrect. Albeit in practice it should be true. (and also, I wouldn't mind the new op)

The below does compile. And it contains "is not".
Never mind, I can't imagine how to fill in the empty bits to make this a useful construct.

program Project1;
{$Mode objfpc}
type
   TFoo = class end;
   TFooClass = class of TFoo;
   TObjClass = class of TObject;
operator not(o: TFooClass): TObjClass;
begin
end;
var a: TFoo;
begin
   writeln(a is not TFoo);
end.

Martin Frb wrote

Never mind, I can't imagine how to fill in the empty bits to make

this > a useful construct.

Fun with operator overloading 😄

Mattias

Op 11-9-2026 om 16:31 schreef Mattias Gaertner via fpc-devel:

 Although I am often unhappy with Embarcaderos syntax choices, the "is not" I like. It looks Pascal, does not bite existing code, is easier to read, and is easy to implement.

But two things to do the same things is nearly always worse.  For that to be worthwhile the advantage must be massive, but that is not really the case. It is superficial it is one of the voted in language extensions.

Yes. I think there are more important issues than saving a pair of brackets and putting words into a more linguistic order.

Michael Van Canneyt wrote

[...] As far as I can see, it cannot break any existing code. So yes, OK.

I created the IsNotOperator branch. Added three tests.

It was so simple to implement, that I wonder if I missed something.

It was more work in pastojs and codetools.

Mattias

Mattias Gaertner via fpc-devel schrieb am
Fr., 11. Sep. 2026, 20:50:

FPC is not always worse XP

Regards,
Sven

Marco van de Voort via fpc-devel schrieb
am Fr., 11. Sep. 2026, 17:43:

Yes. A language should be as orthogonal as possible to avoid confusing users with multiple ways to achieve the same goal.

Thus in my opinion this should be restricted to mode Delphi or at least a modeswitch (same with "not in").

Probably it is one of the voted in language extensions.

And as always it shows that such users always want useless stuff... 🙄

Regards,
Sven

Ehm, boolean expressions are not orthogonal in Pascal: and, or, xor, plus splitting into several if- and/or case-statements - you can express the same function in many different ways. And that is good. No human wants to use only nand.

Orthogonality can be confusing, when it makes the language harder to learn, or it creates ambiguous cases, e.g. due to precedence levels. That's not the case for "is not", or "not in". Even non Pascal programmers immediately understand them (Granted, my test sample is small 😉).

Mattias

Op 12-9-2026 om 00:12 schreef Mattias Gaertner via fpc-devel:

But since the normal math like syntax not (x is a) is as comprehensive, it does not really add much except a few keystrokes.  And it is not common enough to really make saved keystrokes add up.

Its not common enough... Well, maybe its avoided a lot? Chicken or egg?

Btw, FPC (331, few month old) has over 910 of them. Regex:  \bnot\s*\([^(]\s*\S*\s*is\s

And that even excludes any where the 1st arg to "is" has spaces (such as result of a function call with params, or inlined comment, or array index with space // array indexed elem  exists as arg to "is" )

It does more than saving the keystrokes.
It also save on bracket nesting levels. Which translates to: it reduces code obfuscation.

"is" (or "not is") is often in boolean expressions,   if (a is TBase) and ( (not (a is TFoo)) or (not (a is TBar)) ) then ...

Ok usually only one of those is an "is", but then there are other conditions next to the "is", and the "not (.. is ..)" needs one more bracket level, and the start/end of each nest level become harder to find.

(rewriting to have the not further out is possible, but then the original indent is no longer expressed, and that too is obfuscation)

real example from fpc
  While (I>=0) and (Not ((Components[i] is ModuleClass) and (TCustomHTTPModule(Components[i]).KindwkOneShot))) do

The not actually does not apply to the "is" => but you need to look twice at least, to spot the double "((" that expresses this. (this is excluded from the count at the start, as the regex insists on a single opening "(")

To clarify that: This itself wont change by having "Is not". But if a codebase is maintained with "is not" where applicable, the above will stand out as being not "is not". Thus the reader will be more likely to avoid the mistake.

Op 12-9-2026 om 12:57 schreef Martin Frb via fpc-devel:

So any combination that happens a thousand times in FPC sources warrants a language extension? Weird way of reasoning.

It does more than saving the keystrokes. It also save on bracket nesting levels. Which translates to: it reduces code obfuscation.

So how many of those 910 were nested?

Anyway, IMHO it is exchanging math syntax (sometimes with parenthesis, but very general) with very specific semantic syntax.

Yes, occasionally it saves a few parenthesis, but overall the benefits are razor thin. And if you lower the threshold this much, where will it  end?

This is not what I said. I merely said, that your statement "not common enough" is not necessarily applicable.
"not common" is of course subjective.  But 1000 in FPC to me is certainly outside any "black and white" interpretation of "not common".

So that means, your argument against it, is based on a subjective perception.  (there is enough room for enough other people to perceive that otherwise).

* I have not said, that this is an argument for implementing it.
* I have said, that this "removes" (weakens to the point of personal opinion) your argument against it.
=> That are 2 different things.

Well the majority is a list of "and", often each of the sub-expr (between the and) being in brackets => that is not strictly nested. Though if the "not (a is b)" is itself in brackets (which may sometimes be the case, even if not needed), then maybe 100 (this is a very rough guess, the regex engine in the IDE doesn't really allow full checks).

_*But, thanks for the question. *** Because now I have a real feature. ****_

I found several
        while (ParentElnil) and not (ParentEl is TPasProcedure) do
now
   A := nil; b := a is Tobject; // b = false. / at least when I just run it

So if "TObject(nil) is not TPasProcedure" returns false, then the above can be written as
       while ParentEl is not TPasProcedure do

This does depend on how the result for nil will be defined. That hasn't been discussed yet. And "what Delphi does" has not been mentioned.

But if so, then it actually *_is not the same_* :   TObject(nil) is not TPasProcedure       =>  false   not( TObject(nil) is TPasProcedure     => true

That needs to be decided.

Ah, I was almost waiting for the precedence case.

Because, everything sets a precedence. So by that logic, nothing new can ever be accepted. Well, not nothing. But this arguments massively shifts the lines, to create a perceived security....
Such decisions should never use old decisions as precedence. And then new ones can be made without needing to find reject-reasons to avoid precedence for future cases.

> What would be the advantages of this new construct? Delphi compatibility.

If we ant to be more "modern" the we should replace "is not" with "aint" perhaps?
We could leave "is not" in Delphi mode then (for compatibilit).

Even though there are (potentially) gains other than Delphi compatible (see the nil behaviour in the other mail), I don't know if this particular one is worth the diff...

I would have said the "lets do better" about closures => and stripped the anonymous part... but that is done and gone.

Anyway if we go one word, I would (even if it isn't English) go with a single "IsNot".

Martin Frb via fpc-devel schrieb am So.,
13. Sep. 2026, 00:30:

Well there is the merge request for a simplified lambda syntax, though I'll only give my okay for that if it has a significant gain over the anonymous function syntax (my suggestion: the ability for the compiler to generate a runtime readable expression tree for true lambda expressions - that would allow for LINQ-like functionality). However unlike Delphi FPC separates that whole functionality into Function References and Anonymous Functions. If the alter is not enabled FPC still allows the assignment of nested function to function references.

Anyway if we go one word, I would (even if it isn't English) go with a single "IsNot".

That would get a definite "no" for me. I'm not really a fan of this functionality in general, so introducing a new keyword for this nonsense syntactic sugar is a definite no compared to the part of adding this due to Delphi compatibility *behind a modeswitch*.

Regards,
Sven

Sven Barth wrote

[...]> That would get a definite "no" for me. I'm not really a fan of this functionality in general, so introducing a new keyword for this nonsense syntactic sugar is a definite no compared to the part of adding this due to Delphi compatibility *behind a modeswitch*.

Frankly speaking, fpc already has an awful amount of modeswitches. A modeswitch just for "is not" sounds overkill.
Same for "not in".
Maybe we can group such minor delphi peculiarities in one modeswitch?

For example aliasoperators or delphislang ?

Mattias

I hope you realize I was just joking ??

I had a suspicion, but no, ultimately I decided not.

Should add, I should have paid attention to who was making the argument. I just replied to the content (and over the years I have seen many a variation of argument)

I somehow didn't get your joke.

Did you ask me? I listed the only advantage of this construct I can think of. And it is without discussion a valid one, as FPC still hasn't abandoned Delphi compatibility. There is nothing to joke about it. Like the Delphi features or not.

There are real people in this world that want to compile Delphi code with FPC (also 3rd party code).

Ondrej

> I hope you realize I was just joking ?? I somehow didn't get your joke.

[snip]

There is nothing to joke about it. Like the Delphi features or not.

The joke was the contraction of "is not" into "aint", which is kind off "street-talk", whic is "hip", which in turn would make us more modern than Delphi.
It was a "tongue in cheek".
Apparently that intention got lost.
It was in no way meant to critize you opinion on the matter if "is not". If so perceived, then I apologize for that.

A modeswitch DelphiSlang would be useful for the recently added modeswitch UnderscoreIsSeparator as well.

That's also a nice-to-have that ticks all the con arguments.

Mattias

-----Original Message-----

Usually different features are driven by modeswitches. $MODE then selects the needed switches for the mode.

Ondrej

Not all features require specific modeswitches - these are usually used only in case if it is expected / required that developers may enable a particular modeswitch that is _not_ included in the used $MODE, but the developer wants to use it nevertheless.

Tomas

Tomas Hajny via fpc-devel schrieb am Di.,
15. Sep. 2026, 11:01:

It could also be that one wants to explicitly *disable* some functionality which is possible with "$Modeswitch Name-" after all.

Regards,
Sven

The branch IsNotOperator now has a modeswitch DelphiSlang and supports the "is not" and the "not in" operator.

Mattias

Personally, I would use a more neutral term than "slang", such as "dialect" - which also matches what is typically understood when talking about a programming language dialect.

Stefan Glienke wrote

Personally, I would use a more neutral term than "slang", such as "dialect" - which also matches what is typically understood when talking about a programming language dialect.

I would use {$modeswitch combinedoperators} for this - comparable to
{$modeswitch advancedrecords}.

I wouldn't use one big DelphiSlang/DelphiDialect for a summary of recent Delphi language extensions that are not really related.

Ondrej

The point of "is not" and "not in" is not that they are combined or save some brackets, the point is they are English.

Similar with underscored numbers: They are just easier to read for humans.

Probably Embarcadero will add more of such readability extensions.

Maybe DelphiSyntacticSugar ?

Mattias

I don't agree that underscored numerals (which already exist in FPC btw as modeswitch UnderscoreIsSeparator) and these reordering of operators can be considered equally impactful. These operator reorderings should be kept separate from potential other changes so mode switches like "DelphiSyntacticSugar" or "DelphiSlang" are not a good idea. "ReorderedOperators" would be more precise.

Regards,
Sven

Hola,

Sven Barth wrote

considered equally impactful. These operator reorderings should be kept separate from potential other changes so mode switches like "DelphiSyntacticSugar" or "DelphiSlang" are not a good idea. "ReorderedOperators" would be more precise.

May I remind you that `not` is a unary operator that has highest precedence. Thus `MyObject is not MyClass` is grammatically the same as `MyObject is (not MyClass)`. Therefore what is the type of `MyClass` in this expression? It is not a `Boolean`, I guess.

It was equivalent to "MyObject is (not MyClass)".
With the modeswitch it is "not (MyObject is MyClass)".

Mattias

Sven Barth wrote

[...] "ReorderedOperators" would be more precise.

The modeswitch is ReorderedOperators.

Can I merge the branch?

Mattias

I am all for it.

Michael.

Done.

Mattias