Why I don't like implicit self. in classes

That seems odd. What we're you trying to do that required a swift class to be an NSObject for the purpose of a table view? Did you want it to be a delegate/datasource?

And what's so bad about that? All Swift features and performance benefits are all still there. In fact, it's not much different at all, since the Swift runtime is based on the ObjC runtime to begin with. The only differences with an @objc class are that 1) you can optionally access non-private methods dynamically (although Swift callers will still use its usual vtable method), and 2) you can optionally mark things as requiring dynamic dispatch, so that they work with things like KVO and Core Data. Both of these are features that I wish the native Swift runtime had anyway; Swift has a lot of good ideas, but it's also done a good deal of throwing out the baby with the bathwater when it comes to ObjC's dynamic features.

There definitely needs to be some compiler warnings, at the very least, when implicit shadowing is being done. I've been bit by this a few times; it's annoying to try and track down.

I think that there should be warnings as well. This seems to be a language design feature, not a limitation. As with everything in software, it can be abused. Naming is key to avoiding conflicts, unless you plan to always reference things using their full "package identifier" like Go. I'm sure we can do better than this. Just pick good names. Essentially, I believe that this example shows potential confusion with polymorphism. Since print is essentially a "standard library function" (for lack of a better description), it should never be overridden. I think what you found here was a naming decision that was made long before swift was in existence. If Apple has you subclass some class with a method that has the same name as one of the standard functions, it would belong in a trivial radar. Requiring self. This could get muddy quick, because we're not just talking methods here. If you require self, you require it on properties of all accessibilities. From objective-c, this does not seem terrible. We used self everywhere, but adding a stricter grammar requirement will infuriate a lot of people who find this redundant. If a company agrees, I think that the requirement of using self should belong in their coding guidelines. I cannot see Apple pushing a change that would essentially stop all pre-existing, implicit code from compiling. This bug frustrated me, too. It's a prime example of naming conflicts.

I cannot see Apple pushing a change that would essentially stop all pre-existing, implicit code from compiling.

Yes, making changes to Swift that break existing code is certainly something Apple hasn't done any of in the last year. </s>

Yes, I think a compiler warning for shadowing would be ideal. Add my vote for this feature!