5 ms·

I don't use Swift, what's the point of the underscores in the method declaration?

• melling 7y ago
  Without them, you’d need to name the parameters. let z = add(x:2, y:2)
  • virtualwhys 7y ago
    Ok, but I still don't understand, why would you have to name the arguments to the method? Are there other languages with this type of method declaration/use site syntax? If so, what's the advantage?
    • zbentley 7y ago
      There are. Python, Ruby, Perl (sort of), and many other languages via macro/syntax extension (e.g. Rust via https://github.com/comex/namedarg https://github.com/comex/namedarg and an RFC). Do any of them use this specific syntax to disambiguate positionals from named arguments/kwargs? No. Do they all have some form of special syntax in method signatures for making the delineation? Absolutely.
    • pryce 7y ago
      The advantage is clarity in the calling function. With type safety checks, you're mostly eliminating a class of problem by ensuring coders don't call the function with some argumetn of a type they didn't mean to. But suppose I have a method that takes 5 different strings and performs some computation on them - the type safety check doesn't help me there. In functions that take multiple arguments of the same type, it can be easy to be mistaken about the intended order of parameters, for example passing the 5 strings (name, address, level, phonenumber, cellphonenumber instead of in the order the function expects (name, address, phonenumber, cellphonenumber, level). Named parameters -if using meaningful names- make it clear in the calling function the semantics of which parameter has which meaning, so the above mistake gets caught at compile time instead of (worst case) not at all. Of course, in functions with arguments of heterogenous types they're probably overkill.
      • deleted 7y ago
        [deleted]
    • jurip 7y ago
      Others explained what benefit this has, but it's also helpful to understand the Objective-C heritage here. Swift on Apple platforms run on top of the Objective-C runtime, making it possible to call Objective-C from Swift and vice versa. Objective-C uses named parameters. An Objective-C class interface might look like @interface MyClass - (NSString *)methodWithParam1:(NSString *)str1 param2:(NSString *)str2; @end And you'd call it like this: NSString *newString = [myClassInstance methodWithParam1:val1 param2:val2]; The Swift translation layer lets you call that like this: let newString = myClassInstance.method(param1: val1, param2: val) And the translation works the other way around too, making Objective-C able to call a subset of Swift methods that use types representable in Objective-C. You need the named parameters to make it work, because the names of the parameters are part of the method name. So it's a nice feature, but it was also necessary for Apple to be able to make Swift an incremental addition to their platform (yes I know of the Python/Ruby/etc translation layers for Objective-C but they're nowhere near as nice.)
  • stochastic_monk 7y ago
    Meaning that the underscore allows them to be used as positional arguments instead of being only accessed by "keywords", to use a python analogy?
    • emp 7y ago
      They are still positional in Swift. color(r: 255, g: 255, b: 255) is not the same as color(b: 255, g: 255, r: 255). Also the parameter names are part of the method signature.
• cutler 7y ago
  Exactly. I just don't get the buzz around Swift. To me it's just another awful kitchen sink language. Self just makes it worse.
  • donarb 7y ago
    Self is rarely needed with Swift, the only time I use it is when differentiating an instance variable from a local variable with the same name and type.