I guess when I think about it it’s not much different to the JNI support mechanism in Java, just a little more intrusive.
It’s a shame that an “extension” is needed which (to me) adds complexity when there are tokens/keywords in the language already that could have been used to achieve an (arguably) cleaner solution.
That’s all good. Thanks all for your input. My extension is compiling now, especially now that I’ve worked out that I don’t have to “import” the darn thing even though it’s in a file of it’s own.
I have to say that the Apple doc for Swift is not, IMO up to Apple’s normal standard. They do a good job of explain 95% of everything, but don’t actually explain 100% Trial and error programming is way too slow.
I’m not quite sure what you mean here. Are you suggesting that Swift itself (without the current Objective-C interoperability layer) can be made to work with Objective-C?
In Swift, files aren’t imported, modules are.
The documentation was likely written by someone with knowledge of topic; as such, they may have skipped over things that they may have considered trivial. I’m sure they’d be glad to heard feedback about the guide from another perspective so they can improve it.
No. At the moment, I’m aiming for pure-swift but I’m beginning to get the feeling from some of the replies that this might not be possible. I was suggesting that given the opportunity to define the syntax of the ‘pure-swift’ solution, they could have used the ‘optional’ keyword to define base or default implementations of func’s instead of the ‘extension’ mechanism. e.g. to use @Maik639’s code above:
I guess in java I’d have my interface, a base, abstract implementation and that subclass that to provide concrete implementations.
The ‘import’ thing and the concept of a ‘Module’ is obviously something I skimmed. Back to read some more.
It’s obvious to me now that I haven’t read enough of the doc to appreciate the language as a whole. I thought, given I’ve worked with a lot of languages to date, that Swift would just be another C-like language and it would be easy enough to pick up with a read of the intro, and then a reasonable read of the main body of the language reference. I was wrong. Objective-C by comparison is far more straight forward from what I’ve seen so far.
Once I’ve read more and have a better understanding I’ll be in a better position to make suggestions and feedback. It’s clear that I’m not there now.
Thanks again for the answers; and I’m sorry if I’m coming across as critical.
tl;dr: Swift was born out of an Objective-C ecosystem, so it has things to make working in that system easier. But that’s just how it’s going to be on Apple platforms.
If you want to write pure-Swift, then you pretty much have to avoid doing any appleOS related stuff, which unfortunately is still a majority of Swift space. But the server-side (or just Linux in general) application of Swift is slowly reaching the point where you could start doing some actual useful stuff with it. And in those contexts, you only really have pure-Swift and C interop.
But I strongly disagree with the people who say Cocoa/CocoaTouch are part of Swift. They are not. They are part of the Apple ecosystem. Swift is just a language that was born from that ecosystem, so it was built with some things to make working with that ecosystem easier. As time has gone on and the language and Swift ecosystem have evolved it’s become easier to do things in Swift-only fashion. But the fact remains that if you want to write Swift for Apple platforms, you’ll be using Objective-C backed libraries for the foreseeable future.
That being said, there are some features that are @objc only atm like optional methods that could, in theory, be brought into the Swift runtime if they are put through the proposal process. It’s been pointed out that this has already been rejected.
The lack of optional for Swift protocols is intentional and not temporary. See SE-0070:
Swift currently has support for “optional” requirements in Objective-C protocols, to match with the corresponding feature of Objective-C. We don’t want to make optional requirements a feature of Swift protocols (for reasons described below), nor can we completely eliminate the notion of the language (for different reasons also described below).
Swift exposes protocol-oriented programming in a way that you won’t find in Objective-C or Java. While Swift has “C family” roots like those other languages, there are some very deep areas of the language that you will not have experienced before, and this is one of them.
Swift certainly provides nice ways of calling Objective-C libraries, and a lot of work has gone into seamless interoperability between the two languages. With the right amount of @objc sprinkled about, you can indeed use Swift as “Objective-C with a nicer syntax.” However, that is a deceptive façade. It’s only one subset of a much larger and very different language, and it’s the subset that includes perhaps the most exceptions for compatibility reasons.
“Optional requirements” are one such compatibility feature. The spelling “@objc optional” isn’t for the compiler’s benefit–it has no need of the “@objc” and (as far as I’m aware) its implementation in Swift actually has no dependency on Objective-C at all. Rather, this spelling is meant to communicate to you, the writer, that you’re using a compatibility feature implemented only for the sake of Objective-C interoperability. Put another way, the reason you’re required to write “@objc” isn’t because Swift is so similar to Objective-C that it’s borrowing its features, but because Swift is so different from Objective-C that, other than for interoperability purposes, certain Objective-C features wouldn’t exist in Swift at all.
Swift’s tentpole goals are safety (specifically, memory safety), performance, and expressiveness. To make the language a worthwhile contender, it adopts ideas that are either absent in other languages or much less emphasized because they’ve been bolted on later in their evolution. These would include features like optional types (introduced fairly early on to beginners), protocol-oriented programming (more difficult for beginners and a very deep feature with surprising results even for the experienced user), and (soon) ownership (intended to be an advanced feature). Even features that have counterparts in other languages can be quite different. Strings, for example, are Unicode-compliant by default and exposes an API for manipulation that explicitly discourages indexing into them. Mathematical operators have different orders of precedence than in Java or Objective-C (matching Go instead of C).
Chris Lattner likes to say that Swift is actually more complex than C++. The Swift Programming Language, by necessity, offers only a basic primer on each topic. After that, numerous books are now available for in-depth study. Personally, I’ve found Advanced Swift to be indispensable. Past that point, there are numerous resources to be found online for specific topics in Swift programming. WWDC videos and other talks can be helpful. The archives for these forums are also a good resource; they contain in-depth discussion both from the perspective of the end user (Using Swift) and the language designer (Evolution), and they’re now easily searchable.
Here’s the way I would look at this: there are two things going on here.
Swift itself is a stand alone language that is fully independent of Objective-C. You can see this today by using non-Apple platforms like Linux, which do not include or use the Objective-C ecosystem or runtime at all. There are still some minor missing pieces of the story, but it isn’t fair to say that Swift “depends” on Objective-C.
Swift on Apple platforms (which is what you’re referring to) is a superset of the Swift language that includes a bunch of extensions for working with Objective-C APIs. This includes things like optional methods in protocols, bridging, @objc and other attributes for CoreData etc and other stuff that only makes sense to improve the interoperability with Objective-C. Much that complexity is not included in the base Swift language because it really is only there for interop with Objective-C. Careful factoring has been done to make sure that the core Swift language does not include any of that.
Wait wait, I don’t think I’ve ever said that, and I would never enjoy saying that! :-)
I do agree that Swift is not a “simple language” - it definitely does have complicated bits and some other languages are simple. Its approach on this is to factor that complexity so it isn’t in everyone’s face unless they’re deriving some value from it. This is the principle of “progressive disclosure of complexity”.
Thanks @Chris_Lattner3 that is the way I was approaching the language at the start. The only reason I asked the question in the first place was that when I actually started to write my first class which is a port of one I have in an Objective-C project, I hit upon the ‘need’ for optional func’s in a protocol. The documentation that I’d read thus far (the section titled “Optional Protocol Requirements” in the reference) gave me the impression that I had no choice but to include the @objc attribute. That led me to the mistaken impression that Swift could not exist without these “hooks”.
Many have gone to pains to steer me the right direction. It seems that indeed, if I’m using Swift to write apps for iOS, I will at some point have to embrace some of these hooks. My hope is that I can keep that to a minimum; time will tell.
TBF, Chris and I were referring specifically to implementation complexity there. I think fairly uncontroversially, Swift shoulders a lot more implementation burden than C++ does, but it does so with the goal of hopefully reducing user burden in return.
I’d argue that the qualifier is unnecessary. It would be uncontroversial to say that a modern car with, say, a lane departure warning system and automatic parking is more complex than the Ford Model T. A complex tool can be nonetheless intuitive to use.
However, while it may be true that an intuitive tool exposes fewer knobs to turn at any one time, to the extent that we seek to understand the tools we use–and ideally this would apply to the scenario of a programmer understanding their programming language–we do need to reckon with that complexity in some form.
Yes, exactly. In that talk I meant to say that the internals of the Swift compiler are more complicated than a C++ compiler. One example: Swift generics have dynamic/reflective ability + static optimization behavior. C++ templates are a comparatively simple preprocessor.
This design choice is intentional, because in many ways it simplifies the programming model for Swift developers. This is a typical example of “Swift compiler engineers suffering for the greater good of Swift programmers” :-) :-)
Agreed, but there are also better and worse implementations of this. To pick on Swift 1 as an egregious example, it exposed a lot of internal implementation complexity onto the user because so many things were unfinished. As the language continues to mature this will get better and less “in your face” . That doesn’t neglect the need or desire of some users to learn more about the insides, but these are standard tradeoffs provided by high-abstraction tools. We just need to keep working to make it less of a leaky abstraction.
 To be clear, we still have a long way to go, diagnostics are one prominent example.
In my opinion, Apple messed up when they made Swift ‘interoperate’ with Objective-C. They should have delayed the release a year and written the most useful Cocoa API in pure Swift. That would have made the language evolve into what it was supposed to be instead of the bloated convoluted complex language that Swift is today. You could even have an app that uses both Objective-C and Swift - but with a much weaker (say message passing only) interoperability layer.
@tomandersen I suspect that their hands were tied to some extent. If you’re in a big company and you have a bright idea to do something like move the companies development in a new direction, it’s a lot easier to get the money allocated to your idea if you can offer a way to make it seem more palatable to the existing people.
I agree though that in creating a new language, it has suffered as a result of the early need to be compatible. It’s still very early days for me and Swift, and having discovered how much it has evolved in just the two years I’ve been avoiding it, it’s clear that the initial design was either compromised heavily, or the intent and purpose of the language has shifted dramatically (highlighting a possible lack of vision).
The simple act of removing something like the ++ operator shows me that the language now is heading in a different direction to what was originally envisaged (C and C++ familiarity is no longer a consideration). I like that these things have been done, but it seems a shame that the language as a construct has suffered this life of mutation. These sorts of decisions should have happened before it was released into the wild.
Swift was rushed out a bit, but most of that was done by developers rushing Swift 1.0 into production apps as fast as they were legally allowed to do that. Some because it was technically exciting… some to help CV’s ;).