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.)

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.

There are. Python, Ruby, Perl (sort of), and many other languages via macro/syntax extension (e.g. Rust via 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.

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.