Function signature logic swift closure

Programming Languages Swift
Nicpro OP
Created Oct ’15
Replies 21
Boosts 0
Views 3.0k
Participants 6

According to Apple doc the first parameter of a function has its name identifier omitted by default thus the function

func do(something: String, else: String) {}


will be called using

do("first", else: "second")


However, in case where you declare a closure, it appears that the first parameter has to be named which is in contradiction with the documentation. Example:

func activatePlate(plate: String, activate: Bool, callback: (success: Bool) -> Void)
{
    Alamofire.request(.POST, "http://httpbin.org/post").responseData {
      response in
      callback(success: response.result.isSuccess) // <- why that
     // and not that -> callback(response.result.isSuccess)
    }
}
Replies  21
Boosts  0
Views  3.0k
Participants  6
Jens OP
Oct ’15

The parameter naming rules are not the same for functions and closures (even though functions are a special case of closure).

And yes, it would be nice if these (and other) rules could be more uniform, and better documented.

0
Jessy OP
Oct ’15

The reason is that closures only support external parameter names at present.


This should change, and the ridiculous convention of putting the first parameter name outside the parentheses should be abolished. I do not use that convention.

0
Tia Lapis OP
Oct ’15

Well makes coding on Apple systems just harder for you and everyone having to use your code. Is it really so hard to just follow conventions?

0
Jessy OP
Oct ’15

That is false, because this convention is not designed for good code; it's designed for interoperability with Objective-C. If Objective-C wasn't hard to use, we wouldn't have Swift.


Also, the people I work with document their conventions, when they differ from or add to any Apple standard.

0
Jens OP
Oct ’15

I agree, the Objective-C-legacy-induced special case of the first parameter omitting its external parameter name by default is certainly unfortunate, as it makes the language and its documentation more complicated.

0
Tia Lapis OP
Oct ’15

Sure it is - good, readable code was the target when this was designed for the language that grew to be Objective-C.

0
Jessy OP
Oct ’15

I wasn't even alive when that happened. People learned how to make better programming langauges since then.

0
Tia Lapis OP
Oct ’15

So why would falling back to the idiotic way of pure c be better then clear talking signatures?

0
Jens OP
Oct ’15

The current Swift convention is bad because it confuses beginners and annoys people not coming from a strict Objective-C diet.


And C is not exactly the only language that doesn't use this Objective-C-style method/function parameter naming convention.

If it's not about legacy, but rather that the naming convention of Objective-C is superior, why aren't all new languages using it? Can you name one language (except Smalltalk, ObjC and Swift) that uses it?


(IMHO the convention makes much more sense in ObjC and Smalltalk (which is a great language btw) than in Swift, simply because Swift uses parens for function&method calls and around parameter&argument lists, making them part of the reusable/unifying tuple concept.)


EDIT: This is not about having or not having external parameter names, nobody wants to get rid of them, the problem is the special rule applying only to the first parameter.

0
Jessy OP
Oct ’15

C doesn't have external paramer names.


activatePlate(plate: String)

or

activate(plate: String)


The only reason that the second one isn't better is because we've got to do this:

activate(plate plate: String)


Please chill out. 😍

0
Nicpro OP
Oct ’15

Basically what you are saying is that all functions are closures and thus closures that are considered function will get their first parameter name put before the ( and thus become part of the name of the function? function are non anonymous closure?

0
Jens OP
Oct ’15

Here's what The Swift Programming Language iBook says:


Functions are actually a special case of closures: blocks of code that can be called later. The code in a closure has access to things like variables and functions that were available in the scope where the closure was created, even if the closure is in a different scope when it is executed—you saw an example of this already with nested functions.

/.../

Global and nested functions, as introduced in Functions, are actually special cases of closures. Closures take one of three forms:

- Global functions are closures that have a name and do not capture any values.

- Nested functions are closures that have a name and can capture values from their enclosing function.

- Closure expressions are unnamed closures written in a lightweight syntax that can capture values from their surrounding context.


https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html

0
Jessy OP
Oct ’15

Jens, you must realize that a function with a name that includes the first parameter actually has three names for the first parameter, not two, like the rest. 


doThing(thing thing: Any)


The name of a function shall be a verb, not a predicate, in order to avoid that.


Unless it is not a verb, in which case, it returns something, and is is a noun. I mark these with a ribbon emoji.

0
Jens OP
Oct ’15

I'm not sure what you mean, I'm not arguing against you. (I don't like the convention of putting the first parameter name before the first paren either.)

See my earlier reply to your earlier post:

I agree (with you), the Objective-C-legacy-induced special case of the first parameter omitting its external parameter name by default is certainly unfortunate, as it makes the language and its documentation more complicated.

0
CharlesS OP
Oct ’15

The sad thing about it is that Swift's default rule doesn't have to be this way for interop with ObjC. There's no reason that the rules couldn't be consistent, with the bridge just adding a _ before the first argument in a method bridged from ObjC [so -(void)foo:(NSString *)bar becomes func foo(_ bar: String)], and translating things in the other direction using the same rules that are currently used when you explicitly name the first argument. There's no reason to inflict that weird pattern on every single function and method written everywhere.

0
Function signature logic swift closure
First post date Last post date
 
 
Q