New format string for std.fmt.format #8291
Labels
breaking
Implementing this issue could cause existing code to no longer compile or have different behavior.
proposal
This issue suggests modifications. If it also has the "accepted" label then it is planned.
standard library
This issue involves writing Zig code for the standard library.
Milestone
There's a TL;DR go down there if you don't feel like reading all of this.
The problem
Some time ago I was writing a
DateTime
struct and stumbled upon a problem when writing theformat
method for it. My first idea was to use the[specifier]
parameter to format the fields, and everything looked great until I needed to print a:
(ISO8601 format) because you can't scape it in the[specifier]
. There isn't (that I'm aware of) a solution for this other than to create a function to format theDateTime
and print it's result.The other thing I felt a bit bothered was the
FormatOptions
parameter. IMHO I think that thestd.fmt.format
function should be the responsible for thefill
,alignment
andwidth
parameters, andprecision
is a floating point number only parameter (yes, you can find new uses for these in yourformat
function, but you got the point).Adding a condition to escape a
:
isn't that hard but I don't believe this is the way to go.Proposal
I'd to propose the following format string
{[argument][placement]:[specifier]}
, whereplacement => '['[fill][alignment][width]']'
(single quote meaning literal).As I didn't find the issue that explains why
any
became obligatory in first place,any
would maintain the status quo, although I personally don't find that it is necessary.Pros
format
. Ex: anerror
wouldn't get aprecision
parameterargument
inside brackets[]
when referring to it by name, or whenspecifier
starts with a number[]
, symbolizing the box where the value will fit (A really nice way of saying boilerplate)format
don't need to worry about it's positioning:
Cons
format
will have to parse its ownspecifier
(status quo, I guess)Examples
The first line is status quo, the second is the proposal.
TL;DR
Change the current string format from (values inside
''
are literals){[(index|'['name']')][specifier]:[fill][alignment][width].[precision]}
to
{[(index|name)]['['[fill][alignment][width]']']:[specifier]}
so we don't need to escape
:
, or to putargument
inside brackets[]
when referring to it by name or when itsspecifier
starts with numbersThe text was updated successfully, but these errors were encountered: