Lix Development - Public Room Timeline

	Lix Development	408 Members
	(Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel.	135 Servers

Load older messages

Sender	Message	Time
14 Aug 2025
emily	but Nix only has a signed integer type	14:52:35
emily	if we're doing "values outside the range get approximated as floats" a la JavaScript (though note that we losslessly represent more values than JS does already since we have a separate integer type…), then we should do that for too-large signed integers too	14:53:11
emily	otherwise, we should reject out-of-range integers regardless of sign	14:53:31
emily	(this probably means our JSON serialization is nonportable too by RFC rules?)	14:53:41
emily	IOW, the `nlohmann_json` semantics are "we try to find an integer type we can fit a literal into, and otherwise we produce a float"	14:54:35
emily	if we were to implement "we try to find an integer type we can fit a literal into, and otherwise we produce a float" in Nix, we should produce a float for `builtins.fromJSON "9223372036854775808"`	14:54:52
emily	otherwise, if we want "we reject integer-looking literals that don't fit into an integer type, and produce a float only for explicitly float-y values", we should error out on `builtins.fromJSON "-9223372036854775809"`	14:55:16
emily	the current combination of behaviour seems like an unjustifiable accident caused by the impedance mismatch between `nlohmann_json`'s API oriented around C++ numeric types, and Nix's signed-only integers	14:55:45
emily	P.S. I want to cry	14:56:12
WeetHet	@raitobezarius:matrix.org please review https://gerrit.lix.systems/c/lix/+/3862	15:29:28
piegames	In reply to @emilazy:matrix.org IOW, the `nlohmann_json` semantics are "we try to find an integer type we can fit a literal into, and otherwise we produce a float" Thanks, I hate it	15:34:14
emily	well, blame JavaScript :)	15:34:30
emily	(and JSON for not specifying any goddamn semantics at all at first)	15:34:35
piegames	Tbh if a library does untyped bullshit like that, I preferably want it out of my sight	15:34:47
emily	no, this is just JSON	15:34:58
emily	JSON has only one numeric type, because JavaScript does	15:35:05
emily	its type is even vaguer than JavaScript's however	15:35:09
emily	I don't have a strong opinion on "reject integer-looking things that are out of Nix integer range" vs. "always produce floats for things outside of Nix integer range"; both have their merits. the current state seems unjustifiable though	15:35:36
Charles	i thought that JSON just didn't define any constraints on numeric types	15:36:09
raitobezarius	In reply to @weethet:catgirl.cloud @raitobezarius:matrix.org please review https://gerrit.lix.systems/c/lix/+/3862 In ~ 5 days, yeah	15:35:52
Charles	and left that as an implementation detail	15:36:25
emily	it depends what you mean by "JSON".	15:36:29
emily	the original terrible specification defines syntax and says basically nothing about semantics at all https://www.json.org/json-en.html	15:36:45
emily	"A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used."	15:36:51
Charles	lolsob	15:36:56
emily	the latest RFC defines a single numeric type and says This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available. Note that when such software is used, numbers that are integers and are in the range [-(253)+1, (253)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.	15:37:10
emily	* the latest RFC defines a single numeric type and says This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available. Note that when such software is used, numbers that are integers and are in the range [-(253)+1, (253)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.	15:37:16
emily	there is an RFC that subsets it into an interoperable subset that IIRC they say that IETF specifications SHOULD use; I believe it limits the range to the interoperable subset	15:37:39
emily	but I'd have to check	15:37:42
emily	Nix could just always parse numeric literals in JSON into floats, but it would be annoying. (especially since Nixpkgs backs its integer-parsing functions by `fromJSON`)	15:38:05

Show newer messages

Back to Room ListRoom Version: 10