[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 16:19:05 CST 2016


arrhg! typo again!  Closing parenthesis)  removed in 2nd example from behind “temperature”, sorry
> On 12.03.2016, at 22:51, Ted F.A. van Gaalen <tedvgiosdev at gmail.com> wrote:
> 
> 
> 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