[swift-evolution] [Idea] Passing an Array to Variadic Functions

[Thorsten Seitz]

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 <jeremy.j.pereira at googlemail.com>:
> 
> 
>> On 19 Apr 2016, at 10:41, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org>:
>>> 
>>> - Dennis
>>> 
>>>>> On Apr 18, 2016, at 9:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> 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
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>