This doesn't compile with Swift:
class A {
func foo() {
}
}
class B : A {
func foo() {
}
}interface Foo { void foo(); }
class A implements Foo { ... } class B extends A { ... }
If someone renames Foo then A and B fails to compile. If you don't want to use an interface, you do it like this:
class A { abstract void foo(); }
class B { void foo() { ... } }
Yes, it's not exactly equivalent but, this is a rather contrived case that never happens in Java because
a) almost everyone uses @Override because IDEs add it automatically b) Java programmers don't refactor by using VI and editing a base class's method names. An IDE like IntelliJ IDE does all the work automatically. c) if you really want to ensure that a class implements a certain interface, you use a Java interface to enforce it.
This swift feature is interesting, but it's not really anything to sell the language.
I don't think Swift is trying to sell itself based on the 'override' modifier, overflow-checked arithmetic, Unicode variable names, or any of the other minor features which people keep on talking about. It has a far more capable type system than Objective-C ever had. Its pattern matching is far more than "C's switch statement, but without automatic fall-through". Except for backwards-compatibility, it de-emphasizes or eschews the many at-runtime dynamic features that Objective-C had (e.g. creating and modifying classes and methods dynamically). It has tuples. It's a huge departure from Objective-C, not just incremental improvements packaged into a new language (not that it invented these new features, of course), so it's doing more than just addressing 'minor qualms'.