[swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications

[swift at lng.la]

Apologies -- I just realized I chose a bad example that isn't actually using the feature, but the usage would be here:

if successStubs.count > 0 {
    success(successStubs.removeFirst())
}
else if failureStubs.count > 0 {
    failure(failureStubs.removeFirst())
}

Here's a quick modification of the example that would necessitate using the feature:

var getChatMessagesEndpoint = FakeAPIEndpoint(
    calls:        [(channel: ChatChannel, limit: Int)](),
    successStubs: [(messages: [ChatMessage], someOtherReturnValue: Int)](),
    failureStubs: [(error: NSError, status: Int)]()
)

Unless I've overlooked something, when the success and failure callbacks take multiple parameters, calling them in a generic way requires the use of tuple splatting.

Jarod

> On Jan 27, 2016, at 11:10, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Jan 27, 2016, at 11:03 AM, swift at lng.la <mailto:swift at lng.la> wrote:
>> 
>> I'm +1 if this will eventually be replaced with a better-designed version, but I do use it and would be sad to see it go. I've found it very helpful for testing:
> 
> Hi Jarod, where are you using this feature?
> 
>> 
>> protocol APIType {
>>     func getChatMessages(channel channel: ChatChannel, limit: Int, success: (chatMessages: [ChatMessage]) -> Void, failure: (error: NSError) -> Void)
>> }
>> 
>> class FakeAPI: APIType {
>>     var getChatMessagesEndpoint = FakeAPIEndpoint(
>>         calls:        [(channel: ChatChannel, limit: Int)](),
>>         successStubs: [[ChatMessage]](),
>>         failureStubs: [NSError]()
>>     )
>>     
>>     func getChatMessages(channel channel: ChatChannel, limit: Int, success: (chatMessages: [ChatMessage]) -> Void, failure: (error: NSError) -> Void) {
>>         getChatMessagesEndpoint.handleCall(success, failure, callParams: (channel: channel, limit: limit))
> 
> If you are referring to this line, then there is no change.  The only affected case is in call sites that take a single parameter without a label.  Passing tuples as values will not be change.
> 
> -Chris
> 
> 
>>     }
>> }
>> 
>> struct FakeAPIEndpoint<CallParams, SuccessParams, FailureParams> {
>>     private(set) var calls:        [CallParams]
>>     private(set) var successStubs: [SuccessParams]
>>     private(set) var failureStubs: [FailureParams]
>>     
>>     mutating func stubSuccess(params: SuccessParams) {
>>         successStubs.append(params)
>>     }
>>     
>>     mutating func stubFailure(params: FailureParams) {
>>         failureStubs.append(params)
>>     }
>>     
>>     private mutating func handleCall(success: (SuccessParams) -> Void, _ failure: (FailureParams) -> Void, call: CallParams) {
>>         calls.append(call)
>>         
>>         if successStubs.count > 0 {
>>             success(successStubs.removeFirst())
>>         }
>>         else if failureStubs.count > 0 {
>>             failure(failureStubs.removeFirst())
>>         }
>>     }
>> }
>> 
>> It's really nice to have that handleCall method that can call the success or failure callback automatically rather than reimplementing that functionality in every fake API call.
>> 
>> Jarod
>> 
>>> On Jan 27, 2016, at 10:16, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> On Jan 27, 2016, at 2:18 AM, Nisse Bergman <nisse at potmo.com <mailto:nisse at potmo.com>> wrote:
>>>> 
>>>> -1 I use this in both my mocking API and in JSON deserialising/serializing.
>>>> I think this is a great thing to have.
>>> 
>>> Ok, I’m definitely interested in knowing more.  Please include a code sample, showing both the declaration being splatted into and the call sites.  Otherwise, I can’t tell how much value this feature is adding, and what the pain would be if it were removed.  Thanks!
>>> 
>>> -Chris
>>> 
>>>> 
>>>>> On 27 Jan 2016, at 11:07, David Waite via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> I used this just last week! But only as an illustration
>>>>> 
>>>>> +1
>>>>> 
>>>>> One comment though, a splat operator need not be purely syntactic sugar - it could be the way arrays are applied to variadic functions.
>>>>> 
>>>>> -DW
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160127/bcdae87f/attachment.html>