[swift-evolution] [Review] SE-0029 Remove implicit tuple splat behavior from function applications

[Jessy Catterwaul]

I am fine with this proposal, except for having to name the parameter. The argument should be known as $0, within the function. Explanation and example…

My single use case of where this feature might have worked, actually does not. See the double parentheses:

protocol Protocol {
   typealias Arguments
   func ƒ1(parameters: Arguments) -> Arguments
   func ƒ2(parameters: Arguments)
}


struct Struct1: Protocol {
   typealias Arguments = (goodName: String, otherGoodName: String)
   func ƒ1(parameters: Arguments) -> Arguments {
      return (goodName: "", otherGoodName: "")
   }
   func ƒ2(parameters: Arguments) {}
}

let struct1 = Struct1()

// Too many parentheses are needed, but whatever.
// Not a big deal.
let struct1Arguments = struct1.ƒ1((goodName: "", otherGoodName: ""))

struct1.ƒ2(struct1Arguments)


Typealiases fall apart when I need a single parameter:

struct Struct2: Protocol {
   // Should be (goodName: String) but named 1-tuples don't work.
   typealias Arguments = String
   
   func ƒ1(parameters: Arguments) -> Arguments {return ""}
   func ƒ2(parameters: Arguments) {}
}

let struct2 = Struct2()

// No extra parentheses are needed but I don't know what the argument is.
// This is a big deal.
let struct2Arguments = struct2.ƒ1("")

struct2.ƒ2(struct2Arguments)


We need to be able to name the element of a single-item tuple, and we need to stop enforcing internal parameter names:

protocol Protocol {
   typealias Arguments
   func ƒ1(Arguments) -> Arguments
   func ƒ2(Arguments)
}

struct Struct: Protocol {
   typealias Arguments = (goodName: String)
   func ƒ1(Arguments) -> Arguments {
      return (goodName: $0.goodName)
   }
   func ƒ2(Arguments) {}
}

let `struct` = Struct()
let structArguments = `struct`.ƒ1((goodName: ""))
`struct`.ƒ2(structArguments)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160205/01aec110/attachment.html>