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 > <swift-evolution@swift.org> 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 (2...@gmx.de <mailto:2...@gmx.de>) > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution