on Sun Apr 24 2016, Chris Lattner <[email protected]> wrote:
>> On Apr 24, 2016, at 2:33 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: >> >> >>> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution > <[email protected]> wrote: >>> > >>> Hi there! >>> >>> TL;DR: Here’s my idea for a better localized strings handling in Swift. >>> It includes both, support for string interpolation support for >>> NSLocalizedString, and a new string delimiter `...` that can be > used >>> instead of NSLocalizedString("...”). >> >> FWIW, this is closely related to the idea of extending string >> interpolation to support generalized “printf” style modifiers, which >> would allow very expressive formatting inline in a string >> interpolation. This has not yet come to pass, but a write up of the >> ideas are available here: >> https://github.com/apple/swift/blob/master/docs/TextFormatting.rst > > Actually, it looks like the interesting point didn’t make it into the > formal writeup. The idea was to enable something like this (just a > sketch): > > public protocol CustomStringConvertible { > /// A textual representation of `self`. > var description: String { get } > > func formattedDescription(format: String) -> String { get } > } > > Int could then implement support for “x” to print hexadecimal, we > could support left/right whitespace padding, and custom types could > provide their own custom formatters (e.g. a string could have a title > case formatter, or a "look up localized form of” modifier). We could > then provide a “printf” that would allow traditional “%x0” > substitutions. It could also be incorporated into the string literal > syntax by allowing something like: > > let hashValue = 42 // not a good hash function > print(“Hashcode = \(hashValue:x)”) > > This is just a sketch, but that’s the idea. It never went anywhere > because we didn’t have the language features in place to make it work, > notably defaulted implementations in protocols were missing at the > time. 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. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
