> 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. (This would be a big new feature, so personally, I would defer it.) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
