The tuple splat feature you mention below ("foo(test1)", where test1 is a tuple
) is going away in Swift 3, as is the entire idea of modeling a function's list
of formal parameters as a named tuple.
Aside from that, my personal opinion is that forcing a closure to take certain
argument names is way too onerous a requirement for very little benefit. It
would, for example, disqualify the use of the $x wildcards or the use of local
argument names which more precisely represent the semantics of the closure.
Function signatures are already very complicated, so I think any new attributes
or flags should really have a strong argument to justify their inclusion.
Austin
> On Apr 20, 2016, at 10:59 AM, Adrian Zubarev via swift-evolution
> <[email protected]> wrote:
>
> That’s why I’d like to discuss this topic and hear all your feedback.
>
> Do you think it might be possible to add some optional extra flag to the
> language to enforce argument labeling. Not only for tuples as I started the
> discussion with but also for argument labels on blocks/closures?
>
> ```swift
>
> @require_argument_label
> func foo(tuple: (a: Int, b: Int)) { /* do some work */ }
>
> // this will only work with
>
> let test1 = (a: 1, b: 2)
> foo(test1)
>
> func foo(block: (boo: Int) -> Void) { /* pass boo to block */ }
>
>
> foo() { boo in // do is enforced here
> /* do some work*/
> }
>
> // or
>
> foo() { (boo: Int) -> Void in
> /* do some work*/
> }
> ```
>
> An extra flag won’t break any codebase and as an addition will allow some
> good looking syntax at some places.
>
> --
> Adrian Zubarev
>
> Am 20. April 2016 bei 19:47:03, Tino Heth ([email protected] <mailto:[email protected]>)
> schrieb:
>
>> I think it's good that the labels aren't enforced:
>> This would sacrifice flexibility, and force us to write unnecessary
>> boilerplate to "translate" labels (one library might use (height, width),
>> and another (h, w) to express the same concept…)
>>
>> But: Objective-C had no tuples, so a final decision shouldn't happen until
>> there is an agreement on best-practices for them...
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
