[RFC]: support for non-standard specifiers for string formatting

[kgryte]

Description

This RFC proposes adding support for non-standard specifiers for string formatting. Currently, @stdlib/string/format supports the standard printf specifiers as found in C. Would be convenient to be able to support additional serialization formats, such as

• complex numbers (Complex128 and Complex64 with precision and exponential notation formatting).
• JSON
• generic objects
• times
• percentages

Based on the current list of supported specifiers, the following could be potential extensions (although, we'd want to confirm that none of these are already present in common (non-standard) printf implementations):

• Complex128: Z
• Complex64: z
• JSON: J
• object: O (capital o)
• times: D or T
• percentage: p

The tricky extension would be times, as would be nice to support something like YYYY-MM-DD HH:MM:SS, but not clear how this would be done, as this extends far beyond the relative complexity of printf specifier modifiers. Perhaps better would be to have a dedicated time formatter similar to C's strptime and strftime.

My recommendation is that support for non-standard specifiers be included as a package separate from @stdlib/string/format which, IMO, should remain a high fidelity analog of C's printf. Such a package can reuse @stdlib/string/base/format-tokenize, but implement/extend @stdlib/string/base/format-interpolate. The name of this extended package is TBD.

Related Issues

None.

Questions

No.

Other

Prior art:

• d3-format
• d3-time-format
• PEP3101 and Python's format mini-language

Checklist

• [X] I have read and understood the Code of Conduct.
• [X] Searched for existing issues and pull requests.
• [X] The issue name begins with RFC:.

[kgryte]

While full time formatting may be beyond the scope of a @stdlib/string/format extension, something like strptime's %D (for date) and %T (for time) could be possible. This may be enough to satisfy most use cases; however, it would be biased toward English locales.

[Snehil-Shah]

@kgryte has there been any development on this (name of the package)? I would love to help with this. I had a doubt, will Complex128 be formatted as Complex128.prototype.toString()?

[kgryte]

@Snehil-Shah No, haven't had the bandwidth to think about. I updated the labels accordingly.

[kgryte]

will Complex128 be formatted as Complex128.prototype.toString()?

No, not necessarily, as users should be able to specify the desired precision, just as they can with real-valued floating-point numbers. In which case, Complex128#toString() is not sufficient.