[swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others

[Howard Lovatt]

But _ is so easy to type the simplicity of everything is labelled wins for
me. Also remember that inits have 1st argument labels.

  -- Howard.

On 11 March 2016 at 09:21, Kevin Ballard via swift-evolution <
swift-evolution at swift.org> wrote:

> This is a valid concern.
>
> If we assumed that 50% of methods would have a labelled first parameter,
> and 50% would leave them unlabelled, and furthermore we assume that all
> methods with labelled first parameters would use the parameter name as the
> label, then I would support this proposal purely on the grounds that it's
> easier to write `func foo(_ bar: T)` than it is to write `func foo(bar bar:
> T)`.
>
> However, if we assume that the majority of methods still want an
> unlabelled first parameter (which seems like a reasonable assumption to me;
> most of the methods I write would certainly have the first parameter
> unlabelled), and similarly if we assume that a non-trivial amount of
> labelled first parameters use a different label than the parameter name,
> then this change doesn't make as much sense anymore.
>
> Another concern with this proposal is that, even if you assume most
> methods with multiple parameters would want to label all the parameters,
> it's likely that most methods with a single parameter will leave the
> parameter unlabelled. But this proposed rule would cause even
> single-argument methods to label the sole argument.
>
> -Kevin Ballard
>
> On Wed, Mar 9, 2016, at 05:03 PM, Jordan Rose via swift-evolution wrote:
>
> This is my concern too. Our guidelines often lead to the first parameter
> having a label, but usually that name isn't the same as the name of the
> parameter—one's a preposition, the other's a noun. I'm pretty sure the
> common case is still unlabeled. Does that justify the complexity of the
> current rule?
>
> (But because Objective-C methods will now often have labeled arguments, it
> would at least no longer be a marker differentiating "pure Swift" code from
> "Cocoa" code.)
>
> Jordan
>
>
>
> On Mar 9, 2016, at 14:32, Radosław Pietruszewski via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Looking at my code, the majority of methods should still have the first
> parameter unlabeled.
>
> I like the consistency of what you’re proposing and the fact that I don’t
> have to write `func foo(someArgument someArgument: T)` anymore. But I also
> fear people won’t get it that they can (and in many, probably most,
> situations should) make the first parameter `_ foo`.
>
> — Radek
>
>
> On 09 Mar 2016, at 19: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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> *_______________________________________________*
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> 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/20160311/c7095f60/attachment.html>