[swift-evolution] Localization support for string interpolation

[Dave Abrahams]

on Mon Apr 25 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

>> On Apr 25, 2016, at 7:15 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> I believe I also had concerns about this design because it needlessly
>>> misses opportunities for compile-time type safety.  There doesn't seem
>>> to be any reason to embed the format specifier in a dynamic string that
>
>>> has to be parsed at runtime.
>> 
>> I started drafting a post yesterday making the same point, but got bogged down in writing an example of what I *would* want to see.
>> 
>> In brief: printf()-style specifiers are kind of awful. They're very
>> cryptic and unnecessarily unsafe. In C, this problem is addressed by
>> compiler warnings, but Swift already has a mechanism to detect
>> inappropriate combinations of data and operations: the type
>> system. We should use it here.
>> 
>> If we had a protocol to handle formatting, I would want the method's
>> parameter to be of an associated type and typically be something
>> OptionSet-like. It might even be better to structure it as some sort
>> of Formatter protocol. If properly designed, this might allow us to
>> leverage Foundation's existing, fully-featured formatters rather
>> than writing new ones just for Swift.
>
> Keep in mind that succinctness is a virtue, especially when using
> embedded annotations. (I really liked your first go at this) Also
> leveraging training and experience using the (ugly but) time-tested
> shorthand form is not necessarily bad. The safety issue comes more in
> matching types, not in doing something like \(foo.#(%06.1f))

It's not a matter of type or memory safety, so maybe I should have said
that it misses opportunities for static checking.  The problem is that
“.#(%06.1f)” might not apply to foo.

Also, frankly I think printf syntax is arcane and readable only to a
small fraction of developers.  Take a complete read through the man page
sometime if you really want your mind blown!

If you're going to take a string interpolation approach, we can instead
know *exactly* what formatting options apply to “foo,” express them
readably, and check them at compile time.

The problem is that localization may really be incompatible with
Swift-style compile-time-checked string interpolation with embedded
formatting, because of:

1. The need to look up localized strings in tables for a given language,
   making them basically dynamic as far as the compiler is concerned.

2. The need for localizers (i.e. not the application programmer) to
   tune both the string content and how the arguments are formatted.

IMO this problem begs for a holistic solution that integrates a DSL for
localizers with language and library features in Swift.

-- 
Dave