[gurkendoktor]

Many features only exist because Swift needs to work inside an ecosystem built on Objective-C. Otherwise, would we really have both "static" and "class" methods? Or Swift's method declaration/call syntax that looks unlike anything else (except maybe Objective-C)?

I love Objective-C, but I don't want to inherit its baggage (via Swift) when I write backend code.

[plorkyeran]

While Swift's use of argument labels would probably never have existed without the Objective-C legacy, they're pretty much the last thing I'd point to as "baggage". The Swift 1.x version of them was kinda weird, but now that the rough edges have been fixed I'd consider the optional named parameters one of the strengths of the languages.

I really can't think of anything in Swift 4 that exists in the subset of the language supported on Linux which is there for obj-c reasons that I would consider an actual problem.

[gurkendoktor]

I am a big fan of named arguments. But Swift has both argument labels and argument names, and I don't see the point, other than for ObjC compatibility. I find Kotlin's approach conceptually nicer, where parameter names and labels are the same thing.

To give an example (possibly a particularly bad one), UIView.bringSubview(toFront view: UIView) - I feel that the argument label has made it harder, not easier, to give this method a good name.

[protomyth]

> Swift's method declaration/call syntax that looks unlike anything else (except maybe Objective-C)?

Well, Smalltalk actually, and Swift did a poor job of keeping it. Why everything has to look like C or Pascal is a mystery.

Swift makes Objective-C method calls like C with extra punctuation and people add classes to JavaScript. I wish Swift had at least respected that if anything just to cut down on punctuation.

[rimliu]

Well, having 'class' method on struct or enum would look kind of weird, these are value objects, not classes.

[saghm]

So why not just static methods, then?

[salutis]

Static methods are final, class methods are not.

[saghm]

I was responding specifically to the argument that you can't have only class methods because not everything is a class, in which case you could just call them something else other than "class method".