[fpc-devel] is not operator

[Martin Frb]

On 12/09/2026 19:21, Marco van de Voort via fpc-devel wrote:
>
> Op 12-9-2026 om 12:57 schreef Martin Frb 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
>
> So any combination that happens a thousand times in FPC sources 
> warrants a language extension? Weird way of reasoning.

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.


>>
>> 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?
>

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 (ParentEl<>nil) 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.


> 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?
>

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20260912/80e2cb30/attachment.htm>