More std.fmt goodness

[LemonBoy]

I'm pushing this branch so you can give it a spin to make sure there are no regressions and, if possible, find an answer to a few open questions.

The good

• comptime seems to work, stage1 didn't catch fire
• Named arguments are here, enjoy
• Runtime-specified width & precision are now supported
• Thanks to the quasi-equivalence between tuples and anonymous structs (the former are anonymous structures where every field name is equal to its index) we can use the same syntax for named and positional arguments ({[NAME]} or {[POSITION]})

The bad

• Runtime parameters means the options structure is now built at runtime, expect a (small) speed/size hit
• More tests! (Do we need more tests?)
• Documentation needs updating (for the love of $DEITY don't let me write docs)
• You tell me

The ugly

• Duplicate syntax for positionals, you can use both {N} and {[N]} for referring to the N-th parameter. Is this unacceptable and discusting? Is this fine?
  • If we're in for some (Do you use positional specifiers in your format strings?) breakage what about requiring positionals & named arguments to be enclosed in []?
• I hope none of the supposed-to-stay-in-the-compiler machinery finds its way into the final binary
• You

There's no specifier to tell the width/precision is taken from the following argument, do we want that?

[data-man]

Named arguments are here, enjoy

Maybe use @ as additional feature?

try testFmt("hello world!", "{@greeting @who!}", .{ .greeting = "hello", .who = "world" });

[FireFox317]

Maybe use @ as additional feature?

I wouldn't use @. @ should only be used for compiler builtins in my opinion.

[data-man]

@FireFox317

@ should only be used for compiler builtins in my opinion.

and [ and ] should only be used for access by index? :)

[FireFox317]

@data-man

and [ and ] should only be used for access by index? :)

I guess so? I just think we should treat compiler builtins as quite special and thus not use the @ symbol. But any way that doesn't really matter that much :) This PR is huge tho 👍

[LemonBoy]

Hmm, the Windows failure looks legit... Can anyone pinpoint where (and/or on what file) it's crashing?

[marler8997]

I feel like the description is just a test to see who will read it till the end?

[Rocknest]

The ugly (1)(a) 'what about requiring positionals & named arguments to be enclosed in []?'

Seems like a good idea 👍🏻

[andrewrk]

I don't think the issue is caused by this branch - I'm seeing a similar failure in master. I suspect 0f31113

[andrewrk]

can you try rebasing to after f8b3543 ?

[LemonBoy]

can you try rebasing to after f8b3543 ?

Done, but the failure's still there :(

[andrewrk]

I'll help with this eventually, but I do want to focus on my branch #6250 until it's done

[ifreund]

This will be very nice to have for code generation in zig-wayland.

[andrewrk]

I'm happy with merging this as-is. Mind dealing with the conflict(s)?