Deutsch   English   Français   Italiano  
<v3mlrb$c7d5$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Tue, 4 Jun 2024 12:13:15 +0300
Organization: -
Lines: 48
Message-ID: <v3mlrb$c7d5$1@dont-email.me>
References: <v3merq$b1uj$1@dont-email.me> <v3ml0d$bpds$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 04 Jun 2024 11:13:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dce6fda481f9f7f7aa278ce7b31b5172";
	logging-data="400805"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18iQImMO7BDws7Ve5zXFX/X"
User-Agent: Unison/2.2
Cancel-Lock: sha1:Ld7K+mFQMwdCpqDAqVDwDqdSUU8=
Bytes: 2545

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.

-- 
Mikko