[swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others
Ben Rimmington
me at benrimmington.com
Wed Mar 9 15:02:47 CST 2016
+1
I'd like the same rules for subscripts:
e.g. public subscript (_ index: Int) -> Element
And also for closures, so that the Clang Importer can use the same block parameter names as Objective-C:
e.g. public func enumerateByteRanges(_ block: (_ bytes: UnsafePointer<Void>, _ byteRange: NSRange, _ stop: UnsafeMutablePointer<ObjCBool>) -> Void)
The latter wouldn't affect public API, but could be used in Xcode's auto-completion of the trailing closure.
-- Ben
> On 9 Mar 2016, at 18:58, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>
> Our accepted naming guidelines have embraced first argument labels for functions and methods. This weakens our justification for making the first parameter declaration in a `func` declaration behave differently from the others, implicitly being unlabeled. It seems pretty clear to me we should make all of the parameter declarations behave uniformly:
>
> func foo(x: Int, y: Int) // Should declare foo(x:y:), instead of foo(_:y:)
> func foo(_ x: Int, y: Int) // Explicitly declares foo(_:y:)
>
> This would also make `init` and `func` parameters behave consistently, which is nice. There may still be hope for our keyword argument rules to one day be shorter than the Smalltalk spec…
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/60ea78e8/attachment.html>
More information about the swift-evolution
mailing list