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.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 17455 invoked from network); 28 Jun 2023 01:51:34 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 28 Jun 2023 01:51:34 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Tue Jun 27 21:48:38 -0400 2023
Received: from abbatoir (pool-108-27-53-161.nycmny.fios.verizon.net [108.27.53.161])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id b0620ea2 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Tue, 27 Jun 2023 18:48:35 -0700 (PDT)
Message-ID: <BCAFF6B66C40C79524ADFD7C6A6D0C3D@eigenstate.org>
To: 9front@9front.org
Date: Tue, 27 Jun 2023 21:48:34 -0400
From: ori@eigenstate.org
In-Reply-To: <5AE61BE6BDF465DE96BF0C6BEF9C022B@wopr.sciops.net>
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: non-blocking object-oriented DOM firewall high-performance control 
Subject: Re: [9front] Re: cc: support binary constants and refactor
Reply-To: 9front@9front.org
Precedence: bulk

Quoth qwx@sciops.net:
> 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.
> 

while it's a bit surprising to me that you find binary constants
useful (I've never really reached for them), it's a trivial feature
that's already been standardized, and doesn't interact with much.

*shrug* seems good to me.