Re: Interval Comparisons

On 07/06/2024 05:53, Keith Thompson wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 7 Jun 2024 01:52:34 +0100, bart wrote:

The 'a=b' (that's equality)

>
Not in C it isn’t.

 Of course not.  You snipped the part where Bart very clearly said that
he was talking about his own scripting language.  And we're talking
about a proposed new C feature, so I have no problem with references to
other languages.
 And there's precedent in other languages (Python, as Bart already
pointed out) for `a == b < c` being equivalent to `a == b && b < c`,
but with b evaluated only once.
 *If* C were to adopt chained comparisons, I would have no problem
with `a == b < c` being supported with the obvious meaning.
I dislike arbitrary restrictions.  (Though the fact that == and
< have different precedences would have to be resolved somehow.)
In principle it could quietly change the behavior of existing code,
but it's likely that most such code was already wrong.  I don't
advocate making such a change, and I don't think it's likely to
happen, I wouldn't object to it.
 

While it is true that such an addition to C would be very unlikely to break existing code (any current code that uses "a == b < c" or "a < b < c" is probably incorrect), there is a potentially serious consequence that has not been considered here.
Suppose C26 allows "a < b < c" and "a == b < c" chains, like Python, and some people start using it in real code.  You are going to get two effects.  One is that some people will read that new code but not know the new interpretation.  They will think the code parses as "a == (b < c)", and is likely a mistake, or does something different from what it now actually does.
The other is that some people will get used to it and think this is how C treats chained operators.  The code or similar expressions will end up in C code that is compiled under different standards.  Old C standards are used all the time - there are still some people who seem to think new coding in C89/C90 is a /feature/, rather than historical re-enactment.  You would get code that is tested and correct in C26 used incorrectly as C23 or older.
There is also the C++ compatibility question.  C++ provides flexible operator overloading combined with a poverty of available operators, so the relational operators <, >, <= and >= are sometimes used for completely different purposes, similar to the >> and << operators. Chaining relational operators would complicate this significantly, I think.  If C++ adopted the feature it would be a mess to support overloading, and if they did not, "a < b < c" in C and C++ would be valid but with completely different semantics.  Neither option is good.
To me, this possibility, along with the confusion it would cause, totally outweighs any potential convenience of chained comparisons.  I have never found them helpful in Python coding, and I can't imagine them being of any interest in my C code.
Even in a new language, I would not want to see chained relational operators unless you had a strict requirement that relational operators evaluate to a boolean type with no support for relational operators between booleans, and no support for comparison or other operators between booleans and other types.  And even then, what is "a == b == c" supposed to mean, or "a != b != c" ?