Just annotenhere: String intepolation is ok for logging purposes but not for creating user messages which have to be localized (with possibly having to reorder the parameters).
-Thorsten > Am 18.04.2016 um 22:56 schrieb Dennis Weissmann via swift-evolution > <[email protected]>: > > - Dennis > >>> On Apr 18, 2016, at 9:55 PM, Brent Royal-Gordon via swift-evolution >>> <[email protected]> wrote: >>> >>> I would like to see format strings go away and be replace with safer inline >>> annotations. >> >> The main problem is doing localized strings with printf-style formats well, >> but I actually have a pretty sweet solution for that: >> https://gist.github.com/brentdax/79fa038c0af0cafb52dd >> >>> -- E, somewhat agnostic on variadics >> >> Variadics are eventually important as a generic function feature; you really >> want to be able to write a version of zip() which can take any number of >> sequences, for instance, and the only reasonable way to do that is to pass a >> variable number of parameters and return a sequence with a matchingly >> variable number of type parameters. >> > Which brings us to dependent types :) > >> Today, they are important in that they bootstrap ArrayLiteralConvertible and >> DictionaryLiteralConvertible by (at least theoretically) acting as a >> pass-N-items mechanism that doesn't depend on one of the standard library >> types defined in terms of it. (If we convert them to show up as tuples once >> we have tuple subscripting syntax, that will even become true.) Less >> esoterically, they're used in several places where an Array would be >> inconvenient or break traditions: >> >> * The `print` function's list of items to print is variadic. An array >> equivalent would look like `print([one, two, three])`. >> * The `min` and `max` functions are more convenient than explicitly >> constructing an array and calling their `min()` and `max()` methods. >> * And, yes, `String.init(format:_:)`, which we will probably never be quite >> rid of for compatibility reasons. >> > All those points are also perfectly solved by dependent types (which is > definitely not in the time frame of Swift 3 or even Swift 4). > But I think in the long term we should get rid of varargs and Swift 3 (as far > as I remember) is the last version of Swift to remove functionality from the > language (is that actually correct?). > > Short-term solutions: > > I very very rarely use the print function with multiple parameters. Most of > the time I build a single string and use string interpolation to insert > values. If there really is a need for multiple arguments to print, like > others said, overloads could be generated. > min and max: I think most the time they are used to compare 2 values. If > there are more than 2 values (or let’s say 3) I think an array is better > suited. > String.init(format:_:) … I think if all C APIs would get imported by > converting varargs to arrays we could get rid of it. > >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
