Part of me regrets using String(format:) as my go to example of a varargs invocation now. :)
But while the train is off the rails, why introduce a special syntax at all? Since interpolation can include any expression, users can just write small formatting functions and call them there. Pros: We can standardize a few in stdlib, and it would be more extensible than learning yet another string formatting language. Cons: Likely to be more verbose than printf-like descriptors. On Mon, Apr 18, 2016 at 12:27 PM Erica Sadun via swift-evolution < [email protected]> wrote: > This is why god gave us bike sheds. > > Maybe "My earned interest rate this year is \({02.2}theRate)%!" > > -- E > > > > On Apr 18, 2016, at 1:23 PM, Ricardo Parada <[email protected]> wrote: > > > > What would that look like? > > > > > > > >> On Apr 18, 2016, at 3:06 PM, Erica Sadun via swift-evolution < > [email protected]> wrote: > >> > >> > >>> On Apr 18, 2016, at 1:01 PM, Tony Allevato via swift-evolution < > [email protected]> wrote: > >>> > >>> I would also be supportive of removing varargs for now, in favor of a > rethought design when generics are completed. > >>> > >>> In their current form, varargs are fairly limited—because they're > mapped onto an array, the argument types must be homogeneous, so either > your function can only usefully take a single type of argument, or you > potentially lose information because they have to be upcast to a common > supertype or Any in order to build the array. > >>> > >>> I'm not convinced that varargs produce code that is much cleaner than > the array version. Is this: > >>> > >>> String(format: "%@ is %d years old", name, age) > >>> > >>> that much cleaner than: > >>> > >>> String(format: "%@ is %d years old", arguments: [name, age]) > >> > >> I would like to see format strings go away and be replace with safer > inline annotations. > >> > >> -- E, somewhat agnostic on variadics > >> > >> > >> > >> _______________________________________________ > >> 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
