[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