Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #385683
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Interval Comparisons |
| Date | 2024-06-07 02:55 -0700 |
| Organization | None to speak of |
| Message-ID | <87wmn1xek8.fsf@nosuchdomain.example.com> (permalink) |
| References | (6 earlier) <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> |
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 */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 07:14 +0000
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 10:58 +0200
Re: Interval Comparisons Mikko <mikko.levanto@iki.fi> - 2024-06-04 12:13 +0300
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 13:02 +0200
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 12:23 +0100
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 15:24 +0200
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 15:16 +0100
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 17:40 +0200
Re: Interval Comparisons scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 15:27 +0000
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 16:58 +0100
Re: Interval Comparisons Michael S <already5chosen@yahoo.com> - 2024-06-04 19:25 +0300
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 17:54 +0100
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 03:29 +0000
Re: Interval Comparisons Mikko <mikko.levanto@iki.fi> - 2024-06-04 16:11 +0300
Re: Interval Comparisons Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-04 15:42 +0200
Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-04 14:04 -0700
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 11:39 +0100
Re: Interval Comparisons Thiago Adams <thiago.adams@gmail.com> - 2024-06-04 08:32 -0300
Re: Interval Comparisons Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-04 13:37 +0200
Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-04 15:29 -0700
Re: Interval Comparisons Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-06-04 11:41 +0000
Re: Interval Comparisons Michael S <already5chosen@yahoo.com> - 2024-06-04 15:17 +0300
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 23:12 +0000
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-05 00:22 +0100
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 01:30 +0000
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-06 19:48 +0100
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 22:54 +0000
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-07 01:52 +0100
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 02:17 +0000
Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-06 20:53 -0700
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 04:25 +0000
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-07 11:22 +0200
Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-07 02:55 -0700
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-07 13:04 +0200
Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-07 11:57 -0700
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-08 17:42 +0200
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-07 11:28 +0100
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 10:45 +0000
Re: Interval Comparisons Michael S <already5chosen@yahoo.com> - 2024-06-07 14:51 +0300
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-07 13:17 +0200
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-07 13:20 +0100
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-09 13:26 +0200
Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-10 16:33 +0100
Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-10 17:56 +0200
Re: Interval Comparisons scott@slp53.sl.home (Scott Lurndal) - 2024-06-07 14:00 +0000
Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 10:42 +0000
csiph-web