Sujet : Re: Interval Comparisons
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 04. Jun 2024, 22:04:15
Autres entêtes
Organisation : None to speak of
Message-ID : <878qzk1kts.fsf@nosuchdomain.example.com>
References : 1 2 3
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Mikko <
mikko.levanto@iki.fi> writes:
On 2024-06-04 08:58:53 +0000, David Brown said:
On 04/06/2024 09: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
Do you mean, could C treat "a <= x <= b" as "(a <= x) && (x <= b)"
without breaking existing code? The answer is no, C treats it as
the expression "(a <= x) <= b". So you would be changing the
meaning of existing C code. I think it's fair to say there is
likely to be very little existing correct and working C code that
relies on the current interpretation of such expressions, but the
possibility is enough to rule out such a change ever happening in C.
(And it would also complicate the grammar a fair bit.)
<https://c-faq.com/expr/transitivity.html>
>
That does not prevet from doing the same with a different syntax.
The main difference is that in the current C syntax that cannot be
said without mentioning c twice. In the example program C would
require that c is mentioned four times but the shown Python code
only needs it mentioned twice. An ideal syntax woult only mention
it once, perhaps
>
return c in 0 .. 0xD7FF, 0xE000 .. 0x10FFFF ;
>
or
>
return c : [0 .. 0xD800), [0xE000 .. 0x10FFFF] ;
>
or something like that, preferably so that no new reserved word is
needed.
Relatedly, gcc has case ranges as an extension, and there's a proposal
to add them to C2Y (Y=6?):
<
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3269.htm>
The gcc feature uses the existing "..." token rather than "..". I'm not
sure whether using ".." would have caused problems beyond the need to
introduce a new token.
One minor issue, whether the feature uses ".." or "...", is that "1...2"
is a valid preprocessing number (and not a valid literal) so
`c in 1...2` would result in a syntax error. You just need to add
spaces: `c in 1 ... 2` (which I'd argue is a good idea anyway).
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */