`std.fmt`: disallow implicitly formatting optional and error values

On Discord we've discussed and agreed to that it is currently too easy to accidentally pass an optional value (?T) to a format specifier like {s}. It is a real footgun and reminds me a lot to undefined that you can find on JavaScript websites in many places because the developer forgot to handle it. We don't want Zig to be like that. It shouldn't happily print null like that.

@InKryption had the idea of only allowing an optional type to be formatted if there is ? before the specifier type, so for {s} it would be {?s}.

Then @MasterQ32 asked about error unions and I proposed for example {!?s} to format anyerror!?[]const u8. I think this syntax looks really neat and it's consistent with the way the types look.

Here's what cipharius had to say:

That would be definitely more intuitive, as I previously also expected a type error, since in other contexts Zig is pretty strict about type inference.

So the proposal is to change std.fmt formatting such that in a format string

• {t} can only format T,
• {?t} can only format ?T (and T as that coerces to it),
• {!?t} can only format anyerror!?T.

where t is the respective specifier type. This affects all specifier types except for any which will retain current behavior.

CC @InKryption @viriuwu @MasterQ32

[daurnimator]

{?t} can only format ?T,

as T coerces to ?T, should you be able to pass a T?

@daurnimator Yeah, I think you're right. Amended.

[ikskuh]

I don't think this will work out in the proposed way, as this part of the format strings are type specific.

t could mean something else for integers as for custom structs or enums. What i'd propose is that formatting an optional requires the fmt string to be prefixed with ? and formatting an error union must be prefixed with !, where these type formatters remove that prefix and then pass the fmt string down to the original type.

This way, formatting a ?E1!(??E2!?u32) must be formatted as {?!??!?d} for decimal formatting of the u32.

If the prefix is not present, this should be a compile error like

• Formatting optional type ?… must have a '?'-Prefix in the format string: {?…} where the first … is the actual type passed and the second … is the fmt of the original format message

same goes for error unions

[InKryption]

Coming up with a PR for this, I've run into some issues with the design as described here, so I'd like to add an amendment, in order to make this change feasible:

Using the any specifier will allow for current behavior (implicit null and error value unwrapping).

Without this, you run into the issue that fields of containers, such as structs and unions, cannot be formatted with optional or error union fields, as the format specifier used for fields is always any.

@InKryption Oh, sure! any is something that a developer might very well use for debugging or something. There shouldn't be any problem with that.

[LemonBoy]

The resulting symbol soup is quite ugly to read and hard to decypher. If I correctly understand the problem you're lamenting that fmt prints either null or the unwrapped value, an alternative approach would be to make the output "noisier" (eg. rust prints Some(<unwrapped value>) or None) thus forcing the user to properly handle the optional/error case when and if that matters.

[InKryption]

@LemonBoy The issue with that is that it still doesn't catch you when you forget to unwrap the optional/error union, and you only ever see the happy path, which is exactly what the PR for this change uncovered in more than a couple lines of source code in the compiler.

If one really wishes to omit the "symbol soup", as you call it, you can simply use {any}, which will enact the current behavior.

@LemonBoy that does not force the user to properly handle the optional/error case. Making it noiser would only make it worse if it does happen. This proposal makes it so that it doesn't happen in the first place.

[LemonBoy]

Pro-tip, you don't have to put @ tags for every message, this is not twitter.

The issue with that is that it still doesn't catch you when you forget to unwrap the optional/error union, and you only ever see the happy path, which is exactly what the PR for this change uncovered in more than a couple lines of source code in the compiler.

that does not force the user to properly handle the optional/error case. Making it noiser would only make it worse if it does happen. This proposal makes it so that it doesn't happen in the first place.

The happy path means you're seeing Some(<value>) instead of just <value>, for user-facing strings I guess people will unwrap the values to get the latter and handle the case of the value being null.

[InKryption]

The happy path means you're seeing Some(<value>) instead of just <value>, for user-facing strings I guess people will unwrap the values to get the latter and handle the case of the value being null.

That still requires that a path where the value is printed be reached, meaning it's a bug that can remain undetected for an extended period of time. To quote Zen: "Compile errors are better than runtime crashes", which, while this won't result in any crashes, is comparably undesirable.

@LemonBoy thanks for the advice. I might still decide to tag you if I find that it improves clarity.