[swift-evolution] [Proposal draft] Generalized Naming for Any Function
Douglas Gregor
dgregor at apple.com
Mon Dec 28 13:50:52 CST 2015
Sent from my iPhone
> On Dec 28, 2015, at 9:26 AM, Alex Migicovsky via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>>> On Dec 28, 2015, at 10:24 AM, Stephen Celis <stephen.celis at gmail.com> wrote:
>>>
>>>> On Dec 28, 2015, at 11:47 AM, Alex Migicovsky via swift-evolution <swift-evolution at swift.org> wrote:
>>>> On Dec 27, 2015, at 1:32 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>>>
>>>> Some more things to consider:
>>>>
>>>> - Our naming conventions encourage the first parameter to most methods to be unlabeled, so unlabeled parameters come up a lot. I don't think there's a grammatical requirement for an identifier before each colon; maybe we can leave out the underscore and use `foo(:bar:)` instead of `foo(_:bar:)` to refer to unlabeled arguments.
>>>
>>> At first glance it seems like we can remove the parens altogether if we went with this approach. Could instance.`foo:bar:` work (instance.`foo` in the no-arg case)? I’m not sure how removing parens would work for inits and subscripts though.
>>
>> While the conventions encourage the first parameter to be unlabeled, it doesn't enforce it (and there are exceptions in the standard library, like `removeAll(keepCapacity:)`, as well as `stride(to:…)` and `stride(through:…)`.
>>
>> Stephen
>
> Ah right, great point :-)
... And initializers, which often have a labeled first argument, also need to fit the syntax.
>
> - Alex
>
> _______________________________________________
> 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/20151228/fbe268cb/attachment.html>
More information about the swift-evolution
mailing list