Argument labels on blocks arguments should be brought back.
On Wed, Feb 22, 2017 at 4:26 AM Franklin Schrans via swift-evolution < [email protected]> wrote: > I don’t see why it should be available in function arguments. > > The separation of the type and its label makes sense semantically, but the > syntax doesn’t look as pretty anymore. > > Writing something like > foo(completion(success:error:): (Bool, Error) -> Void) {} > seems a bit convoluted to me. We first have to write the labels, then > remember their order to write the type. > > Minor: this also adds additional complexity when Xcode tries to generate a > stub for the closure, as it needs to find the labels in the function name. > > I was thinking of an implementation where closure types could have labels, > but these could only be used within the body of that closure and would be > *erased* elsewhere. This however still makes it difficult for the caller > to figure out what each argument in the closure is representing when using > foo. > > - Franklin > > On Feb 22, 2017, at 9:05 AM, Iain Smith via swift-evolution < > [email protected]> wrote: > > Would this proposed syntax, using argument labels, also be available in > function arguments? > > e.g > func items(withCompletion completion(success:error:): ([Item]?, NSError?) > -> Void) { > ... > completion(success: items, error:nil) > } > > On 22 Feb 2017, at 08:49, Charlie Monroe via swift-evolution < > [email protected]> wrote: > > This was pointed out during the discussions surrounding this proposal and > it was agreed that the type simplification was important. > > There were several suggestions how to bring this back using different > features - e.g. compound names that would contain the labels. For example: > > let callback(success:error:): (Bool, Error?) -> Void = ... > callback(success: true, error: nil) > > This way the type itself wouldn't contain the label information, but the > name of the variable would. > > On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution < > [email protected]> wrote: > > I am quite interested in this as well, thanks for bringing it up! It was > quite disappointing to fall back to multi argument method calls without > labels as it was going against the emphasis on the value of labels in the > language as well as decreasing readability of what is supposed to be self > documenting code. > > Sent from my iPhone > > On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution < > [email protected]> wrote: > > Hi, > > When SE-0111 > <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> > was > approved, I noticed the implication it had when using closures as callbacks: > > Writing > func foo(completion: (success: Bool) -> Void) { > completion(success: true) > } > > is no longer possible, because function types can’t have argument labels > anymore, and the function has to be written: > func foo(completion: (Bool) -> Void) { > completion(true) > } > > which doesn’t look very nice, especially as the number of the arguments > increases. > > After talking to Chris Lattner about this, he referred me to this > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html> > email. > I was wondering if there's been any further work or plans in restoring the > use of argument labels in closures. > > - Franklin > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > _______________________________________________ > 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
