From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 15513 invoked from network); 28 Jun 2023 00:49:23 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 28 Jun 2023 00:49:23 -0000
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Tue Jun 27 20:46:09 -0400 2023
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1687912994;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=dD9rniE+XjKRo60k+G1Cyzr9VzJuUenDqr9DiZrnKug=;
	b=JF9SluzX5w63hKkpgqwPfuucwoszIEZdRt1Fq2kU7uJmaPtA1/rar6uAAIGQYm0Zz7/EeE
	IlkMTXGLFX1XU5Byvq1iZNafQsJ4btIJ5SYR/+0PrbrNm5BuqDWJhcRfiSYdk2hC1DsyVj
	o7GfcSpoT+qOwIv2UxdzyXLWQCisEvc=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id 1ae67c09 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Tue, 27 Jun 2023 17:43:10 -0700 (PDT)
Message-ID: <5AE61BE6BDF465DE96BF0C6BEF9C022B@wopr.sciops.net>
Date: Wed, 28 Jun 2023 02:45:54 +0200
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <91c88c76-7b72-22b8-d9b4-f74171269875@posixcafe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: webscale compliant SOAP over AJAX table configuration manager 
Subject: Re: [9front] Re: cc: support binary constants and refactor
Reply-To: 9front@9front.org
Precedence: bulk

On Wed Jun 28 02:17:19 +0200 2023, moody@mail.posixcafe.org wrote:
> On 6/27/23 16:57, qwx@sciops.net wrote:
> > Thanks; frankly I'm asking because I'm then a bit sceptical as to the
> > utility of this.  What I mean is that there are plenty of deficiencies
> > in C, but this seems like minor syntactic sugar; what else is it
> > alright to add, even if we don't have to care about compatibility etc?
> > But it's already in the tree, and I guess that's similar to adding
> > rc(1) features or syntax, and I don't complain about that, so
> > whatever.  I'm not sure I'm making sense here.
> > 
> 
> It seems your bar for useful is "fixing a deficiency in C".
> My bar for this was: standard, cheap and something I have found myself reaching for.
> I got used to having it around in go.
> That should answer your question for what I consider "fine to add".
> 
> If my thinking here is incorrect we can revert and keep just the bugfix, things
> are not final because they get put in tree.

There's no need to revert anything, I was just wondering what the
rationale was; I haven't seen discussions about it.  If it sounded
like an attack, I apologize.


> > I think it's useful to have an up-to-date document to point to that
> > lists these kinds of additions.  I could perhaps go through the
> > changelog and write a patch when I find the time.
> > 
> 
> Sure, better docs would be great. There are also the undocumented
> kencc magic features like signof(?) and the operator overloading stuff.
> I dont think we need to spell out every standard feature we have, some of
> this stuff can be assumed.

I'll just come back to this with a patch or a list (no promises),
it'll be easier to discuss what to put and what not.

Thanks,
qwx