I thought that strings containing interpolation expressions did require the interpolated expression to be available in the local context. I just checked with IBM's Swift sandbox and indeed got an error when defining a string before the interpolated value, i.e.
let str = "x = \(x)" let x = 1 Therefore I wouldn't expect strings containing interpolation expressions to work when loaded from a file (can't check that in the sandbox, though). -Thorsten > Am 19.04.2016 um 18:42 schrieb Jeremy Pereira > <[email protected]>: > > >> On 19 Apr 2016, at 10:41, Thorsten Seitz via swift-evolution >> <[email protected]> wrote: >> >> 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). > > Reordering is not a problem > > if language == “fr" > { > object = “me” > verb = “lance" > } > else > { > object = “myself” > verb = “throw" > > } > > “Je \(object) \(verb) vers la gloire” > “I \(verb) \(object) towards glory" > > There are other issues though (e.g. format should be in the hands of the > translator) which mean I would not want to lose format strings. > >> -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 > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
