Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Tue, 4 Jun 2024 13:02:03 +0200
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <v3ms7b$d5sq$1@dont-email.me>
References: <v3merq$b1uj$1@dont-email.me> <v3ml0d$bpds$5@dont-email.me>
 <v3mlrb$c7d5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 04 Jun 2024 13:02:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7740955b17fd8df0cccaba227b9e3b39";
	logging-data="432026"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19P777T5QYBNNh1/AbQU5pm8tz8Zmekre8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:i74YjJKIpaurrhsLFJ/hGNpRlFc=
Content-Language: en-GB
In-Reply-To: <v3mlrb$c7d5$1@dont-email.me>
Bytes: 3516

On 04/06/2024 11:13, Mikko wrote:
> 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.
> 

Sure, you can always add new things to a language if they would 
previously have been syntax errors or constraint errors.  But is there a 
use for it?

It is fine if you have a language that has good support for lists, sets, 
ranges, and other higher-level features - then an "in" keyword is a 
great idea.  But C is not such a language, and that kind of feature 
would be well outside the scope of the language.

It would be easy enough to write a macro "in_range(a, x, b)" that would 
do the job.  It is even easier, and more productive, that you simply 
write the "valid_char" function and use it, if that's what you need.