[swift-evolution] Make the first parameter in a function declaration follow the same rules as the others
Ted F.A. van Gaalen
tedvgiosdev at gmail.com
Sat Mar 12 14:18:44 CST 2016
oops !! Errata:
in my examples something went wrong: here they are again, corrected:
> Always specifying labels/names allows us also to have a simpler function syntax as well like so:
>
> bookList.insert( element: book reorderBy: .authorName dropOldVersions: true) // no comma separators
>
> or formatted like this for clarity :
>
> bookList.insert( element: book
> reorderBy: .authorName
> dropOldVersions: true )
>
>
>
Sorry
TedvG
TedvG
> On 12.03.2016, at 20:18, Ted F.A. van Gaalen <tedvgiosdev at gmail.com> wrote:
>
> ( didn’t know it was on its way, so much to read here, missing things at times:
>
> n.b. I’ve just read proposal SE-0046,
> "Establish consistent label behavior across all parameters including first labels”
> Imho it’s an improvement, but it still does not give the consistency/simplicity I would like to see)
>
> To Jake and Erica:
> Just in case you'd think this is a better idea, feel free to adjust your proposal with it. thank you.
>
> ------------
>
> Thank you Haravikk,
> but I’d prefer to have a label obligatory on the first parm as well, for consistency,
> simplicity and readability.
> Also for clarity:
> A parameter name should not be part of a function name.
>
> As in your second example:
>
>> func insert( element: Element ) { … }
>> func insert( contentsOf: Sequence) { … }
>>
>
>
> Always specifying labels/names allows us also to have a simpler function syntax as well like so:
>
> func insert( element: Book inBooklist: Books reorder: true dropOldVersions: true) // no comma separators
>
> or formatted like this for clarity :
>
> func insert( element: Book
> reorderBy: .authorName
> dropOldVersions: true ) -> Bool
> { … }
>
>
> coincidentally, notice this is like in ObjC.. (which i liked)
>
> It also makes the logic with omitted default parameter simpler.
> and would allow an arbitrary parameter sequence in the call, if needed.
>
> (i've appended this possibility later)
>
> I prefer overloading functions in this kind of cases instead of:
>
> insertBook(...
> insertBooks(...
> insertBooksFromArray(...
>
> but maybe that’s just my personal taste.
>
> At the moment I can’t find conflicts with any other language construct,
> also for a new parameter list format without commas,
> does anyone?
>
> TedvG
>
>
>
>
>> On 12.03.2016, at 19:22, Haravikk <swift-evolution at haravikk.me> wrote:
>>
>>
>>> On 11 Mar 2016, at 20:33, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:
>>>
>>> When I started using Swift (on the whole a pleasant journey)
>>> the most confusing thing to me was, and at times still is, the parameter list,
>>>
>>>
>>> I would prefer:
>>>
>>> -uniform for functions(…) AND init(…)
>>> -every parameter must be used with its name/label. Always, no exceptions.
>>> -no shortcuts.
>>> -allow arbitrary parameter sequence.
>>> which is possible and very easy to implement when you always have to use names.
>>> -no trailing commas.
>>
>> I agree, except for labels always being required; sometimes there’s just nothing to be gained by having a label, such as simple initialisers. Also, well-named functions ought to be clear what the first parameter is, for example:
>>
>> func insert(_ element:Element) { … }
>>
>> No-one’s really going to wonder what a value going into a .insert() method is for. However, requiring the developer to choose to add the underscore (as I did above) to enable this gives a balance between the consistency of having all parameters labelled by default, and being able to omit them where it makes sense to.
>>
>> In other words, the parameter can be omitted if its label wouldn’t add anything useful to the call-site. There could be an argument that if .insertContentsOf() were restructured then the parameter might become necessary, resulting in the following:
>>
>> func insert(element:Element) { … }
>> func insert(contentsOf:Sequence) { … }
>>
>> But I think it’s still good for the API designer to have the option, as some cases just aren’t worth adding a label to (or would be redundant). It’s also handy for internal and private methods/initialisers that don’t need the extra clarity.
>
More information about the swift-evolution
mailing list