Path: ...!weretis.net!feeder8.news.weretis.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: Tue, 04 Jun 2024 15:29:05 -0700
Organization: None to speak of
Lines: 59
Message-ID: <871q5c1gwe.fsf@nosuchdomain.example.com>
References: <v3merq$b1uj$1@dont-email.me> <v3mu14$dhe9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 05 Jun 2024 00:29:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e46fb4f9b5052ac42d5a7acf6667e1c2";
	logging-data="653446"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19gXKh9RhTijDPbX7wz5xAo"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:2j2F/fq2TFkxvX5ULdadH1UE21o=
	sha1:er1FYOBRsqWx3a/DP+T05X4kYhQ=
Bytes: 3548

Thiago Adams <thiago.adams@gmail.com> writes:
> On 04/06/2024 04:14, Lawrence D'Oliveiro wrote:
>> Would it break backward compatibility for C to add a feature like this
>> from Python? Namely, the ability to check if a value lies in an interval:
>>      def valid_char(c) :
>>          "is integer c the code for a valid Unicode character." \
>>          " This excludes surrogates."
>>          return \
>>              (
>>                  0 <= c <= 0x10FFFF
>>              and
>>                  not (0xD800 <= c < 0xE000)
>>              )
>>      #end valid_char
>
> See Chaining Comparisons
> https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0893r0.html
>
> https://medium.com/@barryrevzin/chaining-comparisons-seeking-information-from-the-audience-abec909a1366
>
> I don't know what are the current status of this proposal.

That's a proposal for C++.

One interesting piece of information is that the authors did some research
on existing code:

"""
To that end, we created a clang-tidy check for all uses of chained
comparison operators, ran it on many open source code bases, and
solicited help from the C++ community to run it on their own. The check
itself casts an intentionally wide net, matching any instance of a @ b @
c for any of the six comparison operators, regardless of the types of
these underlying expressions.

Overall, what we found was:

- Zero instances of chained arithmetic comparisons that are correct
  today. That is, intentionally using the current standard behavior.
- Four instances of currently-erroneous arithmetic chaining, of the
  assert(0 <= ratio <= 1.0); variety. These are bugs that compile today
  but don’t do what the programmer intended, but with this proposal would
  change in meaning to become correct.
- Many instances of using successive comparison operators in DSLs that
  overloaded these operators to give meaning unrelated to comparisons.
"""

I presume they searched only C++ code, but I'd expect similar results
for C.

As indicated above, such a change would quietly break any existing
code that uses something like `a < b < c` that's intended to mean
`(a < b) < c`, but it would quietly *fix* any code that uses `a < b < c`
under the incorrect assumption that the comparisons are chained.
(Though the latter code will not have been tested under the new semantics.)

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