Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Fri, 07 Jun 2024 02:55:19 -0700
Organization: None to speak of
Lines: 94
Message-ID: <87wmn1xek8.fsf@nosuchdomain.example.com>
References: <v3merq$b1uj$1@dont-email.me>
	<pan$63fde$3c88716e$c61af1ee$d0a27c97@invalid.invalid>
	<v3o706$kfrm$2@dont-email.me> <v3o7jr$ki9u$1@dont-email.me>
	<v3of4h$pbb1$1@dont-email.me> <v3t0aa$1k8ck$2@dont-email.me>
	<v3tene$1n5ge$1@dont-email.me> <v3tlkj$1of9j$1@dont-email.me>
	<v3tqji$1t2fv$1@dont-email.me>
	<87bk4dz9ve.fsf@nosuchdomain.example.com>
	<v3ujg5$20s0s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 07 Jun 2024 11:55:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3ec284f1a7e8071e4d0b56ae14cf643f";
	logging-data="2127204"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18d3iGS10j2fhdYRMnsalK1"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:u3n8L8zPXPYyb/0ECppGvxtMZAo=
	sha1:lwhiICyLqK3Ak7wTKDbHsZa8hxE=
Bytes: 6054

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