Skip to content

feat: Support formatting hex/oct/bin integers#837

Draft
pastelmind wants to merge 1 commit into
toml-rs:mainfrom
pastelmind:integer-format
Draft

feat: Support formatting hex/oct/bin integers#837
pastelmind wants to merge 1 commit into
toml-rs:mainfrom
pastelmind:integer-format

Conversation

@pastelmind

Copy link
Copy Markdown
Contributor

Add methods that create Formatted<i64> in hexadecimal, octal, and binary representations. In accordance with TOML 1.0 spec, these forms can be created only if the integer is nonnegative. For hexadecimal, it is possible to create both uppercase or lowercase representation.

This PR does not change the AST and should be fully backwards-compatible.

Note: See #781 (reply in thread) for the discussion leading up to this PR. This approach is much more conservative than my initial attempts to create a new Integer type that manages the current representation (hex/oct/bin). However, said approach was brittle: it wasn't clear how to classify mixed-case hexadecimals (0xabCDef), or hexadecimals with no alphabets (0x1234). I eventually realized that this was a formatting problem and that adding custom constructors for Formatted<i64> would suffice.

Add methods that create `Formatted<i64>` in hexadecimal, octal, and
binary representation. In accordance with TOML 1.0 spec, these forms can
be created only if the integer is nonnegative. For hexadecimal, it is
possible to create either uppercase or lowercase representation.

This commit does not change the AST and should be fully backwards-
compatible.
@epage

epage commented Mar 3, 2025

Copy link
Copy Markdown
Member

There is a lot of design discussion to be had on this. My general stance is PRs is for implementation discussion and all design discussion should be done in issues.

Since #812 has been created, I'd recommend pushing the discussion there.

@epage epage marked this pull request as draft March 3, 2025 14:59
epage pushed a commit that referenced this pull request Jul 11, 2025
Implements `TomlInteger` and `TomlIntegerFormat` following the
discussion at #812. This supersedes #837.

This design should be extensible in case we later decide to support
integer separators, custom hexadecimal case, or padding (leading
zeroes).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants