Exactly this. I'm holding off on Swift for as long as possible for many of the reasons that others have said better than I can (in a nutshell, it's got all of the bad parts of C++, with few of the good parts of ObjC).
The approach this article suggests would have been ideal; fix some of the warts of Objective C, but stay firmly rooted in its spirit. As things stand now, I'll be learning Swift out of necessity, not desire. And I'll be putting it off as long as possible in the somewhat selfish hope that it's a flop.
Personally I went all-in on Swift. Unfortunately I found that the sceptics were largely right about Swift:
The safety features did not make the code more safe, but caused new classes of bugs. Runtime performance fairly random. Generics caused ten times as many problems as they solved. Optionals simply added runtime crashes, no additional safety.
And this was surprising, given that I regularly program Java with its optionals, use finals everywhere, clearly annotate nullables and of course I use its generics. (Given how poor the generics is in Java, anything would be an improvement, right? Or so I thought)
Programming in Swift isn't anything like programming in Java/C++. It adopts a much stricter typing model - then leaves you hanging without the tools to overcome the consequences of it. Same with generics, stricter constructor rules etc.
The approach this article suggests would have been ideal; fix some of the warts of Objective C, but stay firmly rooted in its spirit. As things stand now, I'll be learning Swift out of necessity, not desire. And I'll be putting it off as long as possible in the somewhat selfish hope that it's a flop.