[swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications
David Waite
david at alkaline-solutions.com
Wed Jan 27 13:32:06 CST 2016
Chris, tell me if this code example clarifies what you are proposing.
Given:
func moveTo(x x:Double, y:Double} {/*…*/ }
moveTo(x:0, y:0)
This is the behavior that is being proposed to be removed:
var point = (x:1.0, y:1.0)
moveTo(point)
instead, I’d have to do either:
moveTo(x:point.x, y:point.y)
or:
func moveTo(point:(x:Double, y:Double)) {
moveTo(x:point.x, y:point.y)
}
today, I’m not entirely sure the behavior if I defined that second function signature. I’m guessing that is one of the motivators to remove this behavior.
-DW
> On Jan 27, 2016, at 12:10 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> 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>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/3cbcfe0a/attachment.html>
More information about the swift-evolution
mailing list