Allow serializing numbers as hex, octal, or binary for readability

[levicki]

Is your feature request related to a problem? Please describe.
Currently it does not seem possible to control serialization of numbers in the library. TOML specification allows numbers to be specified with 0x, 0o, and 0b prefixes. This is a great advantage over other file formats because it allows for serialization of things like hex RGBA color values, Unix permissions, and bitfields/flags in a human-readable format.

Describe the solution you'd like
Implement some way of specifying the number format for insert() and insert_or_assign() methods.

Describe alternatives you've considered
I am not aware of any alternatives.

Additional context
N/A

[levicki]

I hope you didn't forget about this one :-)

[marzer]

Nope, haven't forgotten, just been quite busy of late. Hoping to carve out some toml++ time one of these weekends...

[marzer]

@levicki I've just added the enum toml::value_flags and the corresponding getter/setter pair toml::value::flags(), which will allow you to specify the output format for integers on a per-value basis.

I also taught the parser about this new functionality, so now any special formatting of integers will be round-tripped correctly (e.g. if you read in a hexadecimal integer, change it in code, and re-serialize it to TOML, it will be output in hexadecimal without you needing to do anything different).

I haven't added any ability to do this as part of array::push_back(), table::insert(), and friends just yet, but I'll get to that at some stage.

Also note that the formatting only applies to positive integers, since TOML only allows positive bin/oct/hex literals. If you apply a format flag for one of these to a negative value it will still be emitted in decimal.

[levicki]

@marzer

Sorry for the late reply on this, I was rather busy last two weeks. I hope the lack of my immediate reply didn't leave the impression that I don't care about the effort you put into this feature which I requested.

It sounds great and it seems you did even more than I asked for so thanks, can't wait to test it.

[trcwm]

@marzer Thank you for making this great library! 👍

I too am interested in writing hex integers via array::push_back. Is this still on the roadmap?

[marzer]

@trcwm Glad you like it! Yah this is still on my roadmap, but I've only really had time for bugfixes for much of the last 6 months, and the next aren't really looking much quieter, either. When I get time to do a feature pass over the library I'll happily add this.

[trcwm]

@marzer that would be great - looking forward to it in the future.

[marzer]

@levicki @trcwm If you're still interested in this feature after all this time, I've finally pushed an implementation of this to the v3 branch. All array and table insertion methods will allow you to also pass value flags (with the exception of emplace/emplace_back, because they're variadic so there's nowhere sensible to put the flags parameter).

I won't merge v3 into master for a while yet since there's more work to be done before I cook a new release, but I welcome you to try it before then. (Do note that the v3 branch will be a massive ABI break so I'm not promising it will just work out-of-the-box without requiring a code change or two)

[levicki]

If you're still interested in this feature after all this time...

Yes, thank you.

Do note that the v3 branch will be a massive ABI break so I'm not promising it will just work out-of-the-box without requiring a code change or two

If you are following semantic versioning such a change is to be expected if you are incrementing major version.

As for breakage, don't worry about me -- I always write a wrapper for 3rd party code so I only have to change it in one place.