Re: Interval Comparisons

David Brown <david.brown@hesbynett.no> writes:

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

[...]

*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.

I don't think that's much of a problem.  For a lot of people, the
meaning of "a < b < c" is obvious (and not what C currently provides).
And people reading C26 code need to be familiar with the language.

But ...

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.

That's an excellent point.  The fact that chained comparisons would only
be usable in C26 and later wouldn't be a big problem; most programmers
just wouldn't be able to use them until C26 support is widespread.  But
the fact that chained comparisons silently have different semantics in
earlier versions of C could become a rich source of errors.

Based on that, *maybe* some future C could support chained comparisons
with an incompatible syntax, but I don't think it would be worth the
effort.

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.

I mentioned earlier that someone did a study of open source C++ code and
found no occurrences of things like "a < b < c", except for 4 cases that
were intended to be chained but would behave incorrectly.  I presume
that this study would have covered overloaded operators.

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.

I agree.  I wouldn't mind being able to use the feature, and I think
I've actually used it in Python, but its lack isn't a big problem.

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.

In Python, all comparison operators (<, >, ==, >=, <=, !=, is, is not,
in, not in) have the same precedence, and chained operations are
specified straightforwardly.  They evaluate to a bool result.  Boolean
values can be compared (False < True), which doesn't seem to cause any
problems.

https://docs.python.org/3/reference/expressions.html#comparisons

                                             And even then, what is "a
== b == c" supposed to mean, or "a != b != c" ?

"a == b && b == c", and "a != b && b != c", respectively, except that b
is only evaluated once.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */