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

Tue, 19 Apr 2016 09:43:16 -0700 


> 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























					Reply via email to