Re: [Json] JSON and int64s - any change in current best practice since I-JSON

Carsten Bormann <cabo@tzi.org> Wed, 17 January 2024 17:02 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089CC04B442 for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 09:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mbok9upBT96f for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 09:02:36 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D125EC1519B7 for <json@ietf.org>; Wed, 17 Jan 2024 09:02:24 -0800 (PST)
Received: from eduroam-0298.wlan.uni-bremen.de (eduroam-0298.wlan.uni-bremen.de [134.102.17.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4TFXHM0kF0zDCdY; Wed, 17 Jan 2024 18:02:23 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHBU6isiUhvhk5VPpQ1A_kGDJZhsGLc1xkyu6pNeLUBHw2_dzg@mail.gmail.com>
Date: Wed, 17 Jan 2024 18:02:22 +0100
Cc: Pete Cordell <petejson@codalogic.com>, "json@ietf.org" <json@ietf.org>, Joe Hildebrand <hildjj@cursive.net>
X-Mao-Original-Outgoing-Id: 727203742.588196-df61672cca547edc87f80136eb82f918
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D9273E3-A07F-4303-9AF7-89375FDC2496@tzi.org>
References: <87527a42-aaac-4f39-b320-05f18a2808c1@codalogic.com> <C31BF4C8-9E6C-48F8-BF7B-D2C379273B3F@tzi.org> <CAHBU6it4SaLawSiBgK9ySkbxjtHE6CX-P3r=hzcVy4ksoQo-Cg@mail.gmail.com> <CAChr6SxHfLW-A1asAndKJz-AiyJv5QP18bi=_bNdKXw7zYHThw@mail.gmail.com> <CAChr6SweYdCWxSABZ7g20Zd-xBFzcK0Ritq53S7WtjSwc-vLmw@mail.gmail.com> <E5A68370-CC2F-4618-AB39-39A382656616@cursive.net> <807fea1b-a22b-4d6b-aa5d-720c9b12023c@codalogic.com> <09233A73-3A6B-4E6F-AEB8-596AC6442E24@cursive.net> <869950DC-647B-4481-AEF8-9E092384E99F@tzi.org> <CBD32B58-8328-4602-89C6-BC2A7A875A0D@cursive.net> <994E2C0A-4AE0-4720-8C67-913BBF033E11@tzi.org> <CAHBU6isiUhvhk5VPpQ1A_kGDJZhsGLc1xkyu6pNeLUBHw2_dzg@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/j7bMJ3vNJAUgAyg_XltA5RwJSaw>
Subject: Re: [Json] JSON and int64s - any change in current best practice since I-JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2024 17:02:39 -0000

On 2024-01-17, at 17:57, Tim Bray <tbray@textuality.com> wrote:
> 
> 
> 
> On Jan 17, 2024 at 8:54:40 AM, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> What *is* a “local bigint type” in Rust?  Ruby?  Erlang?
> 
> An integer of unbounded size, no?

But 1 is not of unbounded size, so I don’t understand what 1n means.

The syntax 1n seems to assume that the target platform has a separable type for those integers of unbounded size.  That doesn’t work with platforms where integers of unbounded size aren’t anything special.  It is also weird with platforms that have many bounded types to choose from (is i128 OK for 1n?).

Grüße, Carsten