stdlib-js
[RFC]: support for non-standard specifiers for string formatting
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 (
Complex128andComplex64with 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:DorT -
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:
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:.
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.
@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()?
@Snehil-Shah No, haven't had the bandwidth to think about. I updated the labels accordingly.
will
Complex128be formatted asComplex128.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.