{"id":43329,"date":"2024-05-20T14:46:18","date_gmt":"2024-05-20T18:46:18","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=43329"},"modified":"2025-10-29T09:38:35","modified_gmt":"2025-10-29T13:38:35","slug":"swift-formatstyle-issues","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/05\/20\/swift-formatstyle-issues\/","title":{"rendered":"Swift FormatStyle Issues"},"content":{"rendered":"

Wade Tregaskis<\/a>:<\/p>\n

They’re terser than using their otherwise more powerful cousins the Formatter<\/a><\/code>s, as they support a “fluent” style of property-based access, which tends to read more naturally and usually avoids having to define variables to hold the formatter.<\/p>

[…]<\/p>

They almost always break Xcode’s auto-complete, which is a problem since their syntax is non-trivial and unintuitive.<\/p>

They’re hard to understand – and to even find in Apple’s official documentation – because there’s so many protocols and indirection involved.<\/p>

It’s particularly hard to tell where the inexplicable gaps are. e.g. Double<\/a><\/code> doesn’t support ByteCountFormatStyle<\/a><\/code>, even though logically it should and<\/em> Xcode will sometimes auto-complete as if it does.<\/p><\/blockquote>\n

I haven’t used the new formatter API much because it isn’t available in the SDK that I’m targeting. I like that it’s terser and doesn’t require tracking a formatter instance. But it’s probably not terse enough that I would use it directly vs. via a more semantically named helper method. And I agree that it’s not actually that easy to use if you don’t already know what you’re doing.<\/p>\n\n

Wade Tregaskis<\/a>:<\/p>\n

\n

Alas, they don’t always work correctly; some of these formatters contain egregious bugs.<\/p>\n

In particular, ByteCountFormatStyle<\/code> pretends to support multiple numeric bases – decimal and binary – but it doesn’t[…] Note how it still uses decimal<\/em> units, “kB”. Decimal is not binary. I mean, duh, right? But apparently Apple don’t know this.<\/p>\n<\/blockquote>\n

NSByteCountFormatter<\/code> behaves the same way. I don’t think it’s a bug so much as Apple deciding to never display binary prefixes<\/a> even though it is intentional about calculating memory sizes as binary and file sizes as decimal.<\/p>\n\n

Previously:<\/p>\n