The other thing we've been missing is an equivalent of Clang's -Wformat. That would help too.

@belkadan That was my sentiment in the Radar as well — do we have something tracking that?

My thoughts, since there's nothing private about this:

A version of CFStringCreateWithFormat which takes a number of arguments isn’t any better than what we have today — between the format string and the arguments themselves, the source of truth is taken to be the format string. Because of how C is, there’s no way to know how many arguments are passed in, so there’s no way to validate the input against the source of truth

Adding another parameter adds further potential inconsistency with that source of truth:

• You can mistype the count but have the correct format string and number of arguments

• You can have the right count and format string, but still pass in the wrong number of arguments

• You can have the right number of arguments and count, but screw up the format string

• Rinse and repeat for all combinations, including the count, format string, and arguments being inconsistent

Instead, we have the compiler to verify things in C and Obj-C for CFStringCreateWithFormat and -[NSString initWithFormat:] — both are marked with the same attributes as the printf family of functions so the compiler warns on mismatches and inconsistencies, as it should:

CFStringRef string = CFStringCreateWithFormat(NULL, NULL, CFSTR("%d, %d"), 5); // warning: more '%' conversions than data arguments

If a developer chooses to ignore those warnings, then it’s no surprise if things don’t work.

What we don’t have, though, is a similar facility in Swift:

let str = String(format: "%d, %d", 5)
print(str)

produces no warnings. It would be nice to be able to annotate String.init(format:_🙂 with a similar annotation to keep developers safe in the same way.

We have an Apple-internal <rdar://problem/19414352> -Wformat equivalents for Swift, but no JIRA yet. I don't think it's too hard, but it's no Starter Bug either.

Comment by Federico Cappelli (JIRA)

@itaiferber @belkadan Any update on this? I think that if we want to maintain the use of CVarArg in swift the compiler should help with the format validation implementing something like the objc `NS_FORMAT_FUNCTION()`

A real-life example is os_log, that is the way-to-go for logging but it's a pain to use, with countless crashes due to wrong format strings.

Something like this compiles with no problems :/

os_log("ups %@, %@, %d", "bug!")

I've created an improvement ticket: https://bugs.swift.org/browse/SR-10655

No updates on this yet, but for os_log at least, consider switching to the new osLog interface when available, which does work with string interpolation. I do think that long-term, we'd like to prefer string interpolation over format strings. When everything that format strings can do has made it into the stdlib in one way or another (interpolation is there, but I think we need to offer many more modifiers before it's possible), I'm more than happy to deprecate these.