[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 15:51:39 CST 2016
Variadic parameters? That’s very easy:
// in this example, a: b: c: and d: are parameter names/labels
fooVariadics( a: thing // Easy to parse: the colon : always signifies it is a label, not a var/value
b: 12,45, 65, 56, 456 // b and c are variadic. .
c: “aeroplane”, ”car”, ”rocket” // The commas in-between the variadic values are not interpreted as parameter separators.
d: temperature )
This would work too: (different parameter sequence if you’d prefer to have the variadic parameters (optically) at the end,
in spite of the sequence with which they are declared in the function declaration.)
fooVariadics( a: thing // Parameter sequence can be arbitrary.
d: temperature )
c: “boat”, ”car”, ”rocket” // Note that a trailing comma behind a variadic row would attempt to include the next parameter label
b: 12,45, 65, 56, 456 ) // unless the compiler is a bit smart and sees the colon : of it: but it should raise a compile error in that case.
Two great advantages of this approach without commas would be:
-there is no obligation to put a variadic sequence at the end of the parameter list
-it is now possible to use mulitple variadic parameters.
Ain’t that cool?
TedvG
> On 12.03.2016, at 22:17, Pierre Monod-Broca <pierremonodbroca at gmail.com> wrote:
>
> I'm not for mandatory parameter names, it doesn't always make sense to have them. Besides I don't see much value in removing the commas or reordering the parameters.
>
> By the way how would you do for variadics parameters ?
>
> Pierre
>
>> Le 12 mars 2016 à 21:18, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> a écrit :
>>
>> 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.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list