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

Brent Royal-Gordon brent at architechies.com
Thu Jan 28 00:30:06 CST 2016


> Remove implicit tuple splat behavior from function applications

Please do not remove this without providing an alternative.

I use this pretty frequently, usually in combination with higher-order functions like `map` and `filter` when I'm linking together steps in a pipeline. Here's one example where I'm converting structs into CloudKit objects. I have to perform a series of steps: extract the type and value from the instance (and possibly from its child instances), retrieve or allocate CKRecords for each one, and then write the data into the CKRecords. The top-level flow for this is simply:

    func addInstance(instance: CloudRepresentable, recursively: Bool) throws {
        try typeNameAndValueForInstance(instance, recursively: recursively).lazy.map(recordAllocatorWithVersionMemory(versionMemory)).forEach(writeAttributesAndReferencesToRecord)
    }

Each step in this process is implemented with a private method whose signature matches the methods before and after. This allows me to name each step and encapsulate the details of how they're done. Yes, the signatures are slightly contorted, but they're private methods—implementation details—so it doesn't matter.

    private func typeNameAndValueForInstance(instance: CloudRepresentable, recursively: Bool) -> [(typeName: String, value: CloudValue)]
    private func recordAllocatorWithVersionMemory(versionMemory: CloudDatabaseVersionMemoryType?)(typeName: String, _ cloudValue: CloudValue) throws -> (CKRecord, CloudValue)
    private func writeAttributesAndReferencesToRecord(record: CKRecord, cloudValue: CloudValue)

I agree that the implicit splat causes problems sometimes, but I don't think it should be removed without an alternative. For my uses, simply being able to say `myFunc.apply` for any function (including the ones provided by SomeType.init) would be sufficient. This method could perhaps be overloaded to support all possible combinations of default argument omissions.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list