[swift-evolution] [Proposal Draft] parameter forwarding

[Matthew Johnson]

> On Jan 11, 2016, at 7:53 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Jan 10, 2016, at 7:44 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Proposed solution
>> 
>> The proposed solution is to introduce an automatic parameter forwarding mechansim. It allows users to provide direct arguments for some parameters while forwarding others.
>> 
>> The basic mechanism looks like this:
>> 
>> func foo(i i: Int, s: String, f: Float = 42, d: Double = 43, b: Bool = false) { }
>> 
>> // user writes:
>> func bar(...fooParams) {
>>     foo(i: 32, ...fooParams)
>> }
>> 
>> // compiler synthesizes:
>> func bar(s: String, f: Float = 42, d: Double = 43, b: Bool = false) {
>>     foo(i: 32, s: s, f: f, d: d, b: b)
>> }
> This approach is extremely problematic and unlikely to be accepted.

Ok, I won’t pursue it further in that case.  Thanks for calling that out before I spent any further time on it.

> 
> Swift is carefully designed so that the compiler can type check the interface to a function without type checking its body.  This is important for compiler scalability to large projects, IDE tooling, and also because otherwise you can run into circular dependencies to compile the code.

Good to know.

> 
> Another major problem with this approach is that it only works if “foo” is unambiguous.

I addressed the fact that the call to foo must be unambiguous further down in the proposal.  Did I miss something important?  (Not that it matters if this approach is a dead end)

Do you have any ideas for a better direction that could handle forwarding of default parameter values and / or a subset of parameters?  Or is tuple packing and unpacking the best we can hope for?

Matthew

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