> On Apr 25, 2016, at 7:15 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> 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)) -- E _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
