<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/09/2026 19:21, Marco van de Voort
via fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:15f740e9-20f1-4830-8389-6317697d0b23@pascalprogramming.org">
<br>
Op 12-9-2026 om 12:57 schreef Martin Frb via fpc-devel:
<br>
<blockquote type="cite">
<blockquote type="cite">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.
<br>
</blockquote>
<br>
Its not common enough... Well, maybe its avoided a lot? Chicken
or egg?
<br>
<br>
Btw, FPC (331, few month old) has over 910 of them.
<br>
Regex: \bnot\s*\([^(]\s*\S*\s*is\s
<br>
</blockquote>
<br>
So any combination that happens a thousand times in FPC sources
warrants a language extension? Weird way of reasoning.
<br>
</blockquote>
<br>
This is not what I said. I merely said, that your statement "not
common enough" is not necessarily applicable. <br>
"not common" is of course subjective. But 1000 in FPC to me is
certainly outside any "black and white" interpretation of "not
common".<br>
<br>
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).<br>
<br>
* I have not said, that this is an argument for implementing it. <br>
* I have said, that this "removes" (weakens to the point of personal
opinion) your argument against it.<br>
=> That are 2 different things.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:15f740e9-20f1-4830-8389-6317697d0b23@pascalprogramming.org">
<blockquote type="cite">
<br>
It does more than saving the keystrokes.
<br>
It also save on bracket nesting levels. Which translates to: it
reduces code obfuscation.
<br>
</blockquote>
<br>
So how many of those 910 were nested?
<br>
<br>
</blockquote>
<br>
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. <br>
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).<br>
<br>
<u><b>But, thanks for the question. *** Because now I have a real
feature. ***</b></u><br>
<br>
I found several <br>
while (ParentEl<>nil) and not (ParentEl is
TPasProcedure) do<br>
<br>
now <br>
A := nil; b := a is Tobject; // b = false. / at least when I just
run it<br>
<br>
So if "TObject(nil) is not TPasProcedure" returns false, then the
above can be written as <br>
while ParentEl is not TPasProcedure do<br>
<br>
<br>
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.<br>
<br>
But if so, then it actually <b><u>is not the same</u></b> : <br>
TObject(nil) is not TPasProcedure => false<br>
not( TObject(nil) is TPasProcedure => true<br>
<br>
That needs to be decided.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:15f740e9-20f1-4830-8389-6317697d0b23@pascalprogramming.org">Anyway,
IMHO it is exchanging math syntax (sometimes with parenthesis, but
very general) with very specific semantic syntax.
<br>
<br>
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?
<br>
<br>
</blockquote>
<br>
Ah, I was almost waiting for the precedence case.<br>
<br>
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....<br>
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.<br>
<br>
<br>
<br>
<br>
</body>
</html>