Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
IOS Programming Apple

Swift Vs. Objective-C: Why the Future Favors Swift 270

Posted by samzenpus from the things-to-come dept.
snydeq writes: InfoWorld's Paul Solt argues that It's high time to make the switch to the more approachable, full-featured Swift for iOS and OS X app dev. He writes in Infoworld: "Programming languages don't die easily, but development shops that cling to fading paradigms do. If you're developing apps for mobile devices and you haven't investigated Swift, take note: Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms. Thanks to several key features, Swift has the potential to become the de-facto programming language for creating immersive, responsive, consumer-facing applications for years to come."
This discussion has been archived. No new comments can be posted.

Swift Vs. Objective-C: Why the Future Favors Swift More

Swift Vs. Objective-C: Why the Future Favors Swift

Comments Filter:

  • Uh... (Score:5, Insightful)

    by EmeraldBot ( 3513925 ) on Monday May 11, 2015 @09:13PM (#49669905)

    Since when is embedded programming associated with "immersive, responsive, consumer-facing applications"? I don't think Swift is going to replace C anytime soon in that department.

    • Re:Uh... (Score:5, Insightful)

      by Entrope ( 68843 ) on Monday May 11, 2015 @09:15PM (#49669915) Homepage

      More to the point, who outside Apple develops embedded software for an Apple platform?

    • Since when is embedded programming associated with "immersive, responsive, consumer-facing applications"? I don't think Swift is going to replace C anytime soon in that department.

      It was not obvious from the summary what the heck was meant by "embedded programming". In TFA, in addition to the quoted paragraph, the word "embedded" is also used in "The ability to defer loading in a mobile app or an embedded app on Apple Watch will improve the perceived performance to the user.", "Swift provides the development community a direct way to influence a language that will be used to create apps, embedded systems (if Apple ever licenses an embedded framework and chip for third parties), and

    • Since when is embedded programming associated with "immersive, responsive, consumer-facing applications"? I don't think Swift is going to replace C anytime soon in that department.

      I think their idea of an "embedded system" is one where you "embed" an Apple product into it. And sure, by the strict definition you are embedding a computer in something. I'm sure there will be a market for such devices going forward. But that's really a very small corner of the embedded systems world.

      I doubt very much the author of the article has any real idea what a true embedded system really is.

      • Re: (Score:2)

        by jythie ( 914043 )
        Given the author's proclamations and supporting facts, I doubt the author has much of a real idea of anything in computing outside their narrow niche.

  • Unlikely (Score:5, Insightful)

    by msobkow ( 48369 ) on Monday May 11, 2015 @09:16PM (#49669923) Homepage Journal

    It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.

    • Re:Unlikely (Score:5, Interesting)

      by Trepidity ( 597 ) <[delirium-slashdot] [at] [hackish.org]> on Monday May 11, 2015 @09:50PM (#49670097)

      I think a wholesale rewrite is unlikely, but I would guess that they are going to eventually do something about the GNU code they use. Apple doesn't like the GPLv3's patent clauses, so they have frozen all their imported GNU utilities at the latest GPLv2 version. Some of these are now getting quite old and not maintained upstream, so Apple has to handle even routine maintenance. They managed to transition off one big one by moving from gcc to clang/LLVM, but there is still a bunch of old GNU code shipped in the base system that I don't see them keeping forever. Now whether they rewrite it in Swift seems more questionable.

      • Re: (Score:2)

        by jythie ( 914043 )
        I keep hoping there will be a resurgence in GLPv2 development. While Apple is a high profile example, companies that work with embedded software have generally not been happy with what many feel were changes singling them out while not putting the same burden on other GPL users, kinda like sacrificial goats. The politics behind GPLv3 and who's needs it prioritized left a bad taste in some people's mouths.

    • Re:Unlikely (Score:4, Insightful)

      by Feral Nerd ( 3929873 ) on Tuesday May 12, 2015 @07:19AM (#49671975)

      It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.

      Precisely, that's what wrapper code has been for since I started coding back in the early 90s. It always cracks me up when people let fly gold nuggets like "...the Python implementation of OpenCV...". As far as I am aware, nobody rewrote all of OpenCV in Python, they created Python bindings [python.org] which is a fancy way of saying they created a Python wrapper for OpenCV. Programmers don't always realise that the API's they are using are actually wrappers. I used to use a C++ Linear Algebra library but because I just installed it with yum or apt-get I didn't pay it much thought. it wasn't until I tried to compile it for an embedded computer that I realised the thing was actually a wrapper for a Fortran 77 library that was ported to Fortran 90 and then given a C++ wrapper and that made it a bit of a bitch to compile (largely due to the fact that I didn't know squat about Fortran). Apple will provide Swift wrappers for at least some of the C/C++ libraries and the ObjC stuff if that's necessary (never used Swift myself so I don't know how well ObjC libraries integrate into Swift). Any other approach would have Apple's developers busy doing nothing but rewriting and debugging ported code for the next decade at least. What interests me is how far up shit creek will a developer be if he/she realises that they need a C/C++/ObjC library for his Swift application?

  • On iOS platforms. (Score:5, Insightful)

    by FireballX301 ( 766274 ) on Monday May 11, 2015 @09:19PM (#49669941) Journal
    The future favors Swift only because Apple is going to phase out use of ObjC. That's it. Arguing about languages is silliness when Apple will likely force you into using Swift for iOS9 compatibility in the next 12 months.

    • Re: (Score:2)

      by jeremyp ( 130771 )

      Apple will likely force you into using Swift for iOS9 compatibility in the next 12 months.

      Nope. That is not going to happen unless they don't care about 95% of the apps on the app store not working on iOS 9. It's more likely that they will just not make new APIs available in Objective-C, so that Objective-C apps can't use the latest features.

  • I donno. "development shops that cling to fading paradigms do [die]." Obj-C is a perfectly good tool. Fortran and COBAL as still used all over the place. The only way Obj-C dev shops are going to die is if Apple makes it so (and I have no doubt they will). But I think this fundamental argument is flawed if not downright wrong.

    • Re: (Score:3)

      by _merlin ( 160982 )

      What's with the outbreak of people who can't spell COBOL? It's like kids are trying to sound older than they are by using jargon but completely screwing it up.

  • Debate settled. We know the future! (Score:5, Funny)

    by Paradoks ( 711398 ) on Monday May 11, 2015 @09:21PM (#49669957) Homepage
    It's nice that there's a programming language debate where the future has been entirely settled. Thanks infoworld!
    • There's a new version of Siri, coded in Swift, that answers your questions about the future. It was released next December.

  • Objective-C was ahead of its time (Score:4, Funny)

    by jblues ( 1703158 ) on Monday May 11, 2015 @09:45PM (#49670077)

    Objective-C was ahead of its time. It uses messaging for communication between Objective-C, and using "the runtime" (a tiny virtual machine that is embedded into each executable) messages are resolved to a function pointer. Other compiled languages use static dispatch, vtable dispatch (allows overriding) or in-lining. However, messaging gives an advantage in that it affords features that are available in higher-level 'interpreted' or 'managed' languages:

    • * Object introspection - describe the methods and properties of an object
    • * Dynamic invocation - reflectively invoke methods of an object.
    • * Method interception - add or reroute methods for all instances or a single instance of an objection, optionally calling the original.

    The above features allow all kinds of useful things like Aspect Oriented Programming, instrumented objects at runtime (eg for object-relational-mapping), Cocoa's elegant property observers, etc. Another advantage is that Objective-C is close to the bare-metal so its very easy to take advantage of the above, while dropping back to raw C (or C++) as needed for performance tuning, which given the 95-5 rule is not too often.

    Contrast these dynamic features, with C++ which fills another niche. Now the industry has had 30 years to forget how useful these features are, so Swift uses static and vtable dispatch. Given a virtual machine, with just-in-time compilation this is no problem, but as a compiled language it means forfeiting the above. Swift allows the above if a class extends a Cocoa Foundation class, but this problems are:

    • * Developers are excited about writing 'pure' Swift.
    • * The advantage or dynamic dispatch is that it can be applied to any class. Now if Swift adds compile-time AOP, this will only work with code that you have the source for.

      • I'm surprised more people didn't raise concerns about this.


    • * Object introspection - describe the methods and properties of an object
      * Dynamic invocation - reflectively invoke methods of an object.
      * Method interception - add or reroute methods for all instances or a single instance of an objection, optionally calling the original.

      All that has nothing to do with "message passing".

      • Re: (Score:3)

        by jblues ( 1703158 )

        * Object introspection - describe the methods and properties of an object * Dynamic invocation - reflectively invoke methods of an object. * Method interception - add or reroute methods for all instances or a single instance of an objection, optionally calling the original.

        All that has nothing to do with "message passing".

        You think so?

        Runtime method interception is supported in languages that use vtable style dispatch rather than messaging, only because these languages feature a virtual machine, and class-loader. Otherwise the function-pointers are compiled right in. It is not possible to perform method interception without evil [github.com]. With Objective-C we can perform method swizzling - modify the lookup table to resolve methods to a function pointer) or isa swizzling - change the 'class', to a dynamically generated one, for a giv

        • You think so?
          Yes, I do.

          No idea what you want to say with the two paragraphs you "quote".

          They again have nothing to do with "message passing".

          The question if you can do "Reflection/Introspection" is answered by having meta data of the classes available and an API to query it.

          E.g. Java supports reflection and introspection and: does not use message passing!

          • Re: (Score:3)

            by jblues ( 1703158 )

            E.g. Java supports reflection and introspection and: does not use message passing!

            Read my comment again. I said that Java supports method interception while still using vtable dispatch. The reason for this is that it has a virtual machine and class-loader, which provides another point of interception. Examples of this are:

            • * The hibernate library uses cglib, which is in turn uses asm, to provide managed objects. You write a plain-old Java object and hibernate instruments this at runtime.
            • * Spring uses cglib or the aspectJ weaver to provide AOP features, such as annotation-based declarati

    • Re: (Score:2)

      by jblues ( 1703158 )

      It uses messaging for communication between Objective-C

      doh - I meant to write 'for communication between objects', ie method invocation.

  • What is Swift written in? (Score:5, Informative)

    by Areyoukiddingme ( 1289470 ) on Monday May 11, 2015 @09:52PM (#49670113)

    What is Swift written in?

    It is built with the LLVM compiler framework included in Xcode 6, and uses the Objective-C runtime...

    So... C. Ok, we're done here.

    No wait. One more thing. It's the Objective-C runtime. Which means Objective-C programs will just keep running, as they ever have.

    Swift and Objective-C code can be used in a single program, and by extension, C and C++ as well.

    The new language can't supplant the old one while the old one exists in the same environment. More to the point, compatibility with Objective-C, C, and C++ was an explicit design goal. So you can just pack up all the bullshit about taking over the world.

    • The new language can't supplant the old one while the old one exists in the same environment. More to the point, compatibility with Objective-C, C, and C++ was an explicit design goal. So you can just pack up all the bullshit about taking over the world.

      Thank you! I was scrolling through the comments and took a damn long time before I found someone else that had the same thought I did. All Swift seems to be is a higher-level abstraction of the same animal ... C If that's the case, C, C++ and Obj-C will still be around for a long time on the platform and Swift will just jump in the bus with them.

    • Re: (Score:2)

      by T.E.D. ( 34228 )

      What is Swift written in?

      It is built with the LLVM compiler framework included in Xcode 6, and uses the Objective-C runtime...

      So... C. Ok, we're done here.

      That means nothing of the sort. LLVM is a compiler framework, whose back end contains rather a lot of machine language, and whose front end depends on the language being used. Most language front ends are self-hosted (written in themselves).

      Likewise, using the Objective-C runtime doesn't mean anything other than that it was a convenient runtime that already existed, and they know how to interface to it. If you can do that, your sources can be in any language you prefer.

      But most importantly, C fans seem

  • More approachable? (Score:3, Interesting)

    by Dog-Cow ( 21281 ) on Monday May 11, 2015 @09:53PM (#49670119)

    I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.

    let versus var
    optionals, including implicit and explicit binding
    differences between structs and classes (value versus reference)
    generics
    different ways of specifying parameters, including named and unnamed parameters
    property declarations, including a multitude of shortcuts

    The problem is, if you don't learn most of the syntax in all its variety, you'll have a hard time understanding any random code you come across. Learning by example helps make a language approachable.

    • I disagree (Score:5, Insightful)

      by SuperKendall ( 25149 ) on Monday May 11, 2015 @10:18PM (#49670265)

      I've done Objective-C since before the release of the iOS App Store, and Swift almost full time since Apple released it last year...

      Some of the things you mention beginners do not have to use (generics, and struts for example). To keep things simple to start with, they could just use classes instead.

      I will agree that optionals might be a bit rough on the beginner - but perhaps not as starting from nothing, the concept of a bucket that holds a value instead of just using the value directly, would not be so foreign...

      You also mention different ways to specify params, and shortcuts - but I see those as a major plus. You can just pick a level of detail that makes sense to you and work with that, until you feel comfortable with reducing further the syntax you use.

      I think the function syntax is one of the cleanest and easiest styles to understand... I believe a few other languages have this form also, but in swift you just say something like "a function named takes in these params, and outputs those params" So it looks like:


      func myFunc (a:String, b:Int) -> (a:String, b:Int)

      it's just so balanced that you can have any number of things in or out.

      There are a few things I think make Objective-C less approachable.

      The separate header files, and the heavy modern use of private categories to define most internal properties confuse people as to where they need to define things.

      Simply more verbose syntax all over. I like verbosity myself, I love named parameters... you get that with Swift though with a lot fewer characters typing.

      Part of that extra syntax in ObjC is the shorthand to make arrays like @[] and @(value) to make NSNumbers... but in Swift Integer is treated the same as String, both are first class objects that you can do things with so it's more consistent. That in particular is I think a large benefit for newcomers.

      • Re: (Score:2)

        by Dog-Cow ( 21281 )

        I like syntactical shortcuts too. Apple has added many to Objective-C over the years, and I have welcomed all of them. However, there is still a single style. For any particular feature, there's one syntax that works. Contrast with Swift. Even if you learn only one style and stick with that until you're comfortable, it's hard to learn from others because code can be in so many different styles. If you hit a shortcut you're not familiar with, you hit an obstacle. By definition, a path with obstacles i

    • Re: (Score:2)

      by MassacrE ( 763 )

      I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.

      let versus var

      const char* vs char* vs char const*
      NSInteger vs const NSInteger
      NSString vs NSMutableString

      optionals, including implicit and explicit binding

      NSInteger vs NSInteger*
      nil vs NULL vs NSNull

      differences between structs and classes (value versus reference)

      NSInteger vs NSColor

      generics

      vs not having generics :-)

      different ways of specifying parameters, including named and unnamed parameters

      vs:
      [NSString stringWithFormat: @"%@", value]
      [NSString initWithFormat: @"%@" arguments: va_arg]
      NSStringFromPoint(pt)

      property declarations, including a multitude of shortcuts

      vs
      @property(readwrite,copy) NSString* foo;

      The problem is, if you don't learn most of the syntax in all its variety, you'll have a hard time understanding any random code you come across. Learning by example helps make a language approachable.

      The problem is that you are judging a new language's learning difficulty by comparing it to a language you already know.

      That said, Swift is not solid enough to live there 100%

    • I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.

      let versus var

      Neither "var" nor "let" is more approachable to someone not already informed. Programmers know variables, mathematicians are familiar with the "let" convention.

      optionals, including implicit and explicit binding

      Optionals are actually pretty intuitive when you're not already in the programmer's mindset. Why can't we simply ask whether something is there or not? Many languages force you into all sorts of silly workarounds, including subtyping, flag management, or (lazy man's favourite) exception handler.s

      differences between structs and classes (value versus reference)

      There's never an easy answer to that one. Values are fa

  • Swift is not ready to replace ObjC (Score:4, Insightful)

    by Anonymous Coward on Monday May 11, 2015 @10:03PM (#49670171)

    > 8. Swift supports dynamic libraries

    The swift runtime is a static library (written in C++11) and linked in every executable, everytime there's an update to swift (runtime) you need to recompile all your code (see Apple's swift blog, first entry). This is why swift cannot be used for system API / libraries, at least until they have a stable runtime that can made a dynamic lib (like Obj-C is). But it being C++, I don't know if that ever gonna happen.

    • Re: (Score:2)

      by Smurf ( 7981 )

      The swift runtime is a static library (written in C++11)

      I had absolutely no idea that the Swift runtime was written in C++11. Can someone please provide a link to this, since the parent is an AC?

      • Re: (Score:2)

        by Dog-Cow ( 21281 )

        A significant, though perhaps still minor, portion of Cocoa Touch is also written in (Objective-)C++.

      • Re: (Score:2)

        by jeremyp ( 130771 )

        Swift Blog July 11th 2014 entry [apple.com].

        you can target back to OS X Mavericks or iOS 7 with that same app. This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases.

        The embedded part is actually quite small and it's only there because the language is still evolving (and to allow apps to target the previous versions of OS X and iOS). The main re

  • I'll start using Swift (Score:3, Insightful)

    by SpaghettiPattern ( 609814 ) on Monday May 11, 2015 @10:25PM (#49670295)
    I'll start adopting Swift as soon as it has an active community on most commercially interesting platforms. E.g. all UNIX derivatives, Windows, z/OS and Mac of course. When I have ample choice of programmers to hire. Not interested in technologies exclusively centered around one supplier.

  • Replace C? (Score:3)

    by fozzy1015 ( 264592 ) on Monday May 11, 2015 @10:29PM (#49670317)

    "Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms."

    Not if you want to write something that compiles on other platforms. With Android/iOS being based on Linux/BSD it could very well make sense to write the back end of your app in C/C++ and only then branch into a different language as required by the GUI framework and other required proprietary APIs you'll be using.

    • Re: (Score:2)

      by jblues ( 1703158 )

      "Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms."

      Not if you want to write something that compiles on other platforms. With Android/iOS being based on Linux/BSD it could very well make sense to write the back end of your app in C/C++ and only then branch into a different language as required by the GUI framework and other required proprietary APIs you'll be using.

      We tried this. It turned out to be not much fun. (Thought maybe we weren't doing it right).

      • * When the kernel is C++, unless you write a native language interface, it exposes the developers to C++. Its difficult to find developers who are good at C++, Objective-C and Java. Even experienced developers can make mistakes with regards to memory management.
      • Threading is usually a big concern. In Objective-C/C/Swift tools like grand-central dispatch make this easy, however in C++ its p-threads. C++11 has threads

      • We tried this. It turned out to be not much fun. (Thought maybe we weren't doing it right).

        To be fair, my experience with this was taking a Windows/Mac OSX program written by predominately C++ programmers and porting it to iOS and Android. The C++ code was already well debugged.

        Threading is usually a big concern. In Objective-C/C/Swift tools like grand-central dispatch make this easy, however in C++ its p-threads. C++11 has threads, but this isn't supported by Android yet.

        The native environment give you an API of libraries and a community of open-source projects to fill in the gaps. With C++ you have identify and source your own stack. Poco or boost. etc.

        Boost assuredly. It's what has been incorporated into C++11 and makes up the bulk of its new features(e.g. you mentioned threading).

    • "Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms."

      Not if you want to write something that compiles on other platforms. With Android/iOS being based on Linux/BSD it could very well make sense to write the back end of your app in C/C++ and only then branch into a different language as required by the GUI framework and other required proprietary APIs you'll be using.

      I take it you've never written cross-platform code for MacOS? There's a lot of things like memory management, for one, that you'd want to use Obj-C for. By the time you've done all the "required proprietary API" changes, you'd have been better off just writing the whole thing in Obj-C. Not only would it save dev time, the end product would be a lot more stable and have better overall performance, but I guess it depends on what trade-offs you're willing to accept.

      • I take it you've never written cross-platform code for MacOS? There's a lot of things like memory management, for one, that you'd want to use Obj-C for. By the time you've done all the "required proprietary API" changes, you'd have been better off just writing the whole thing in Obj-C. Not only would it save dev time, the end product would be a lot more stable and have better overall performance, but I guess it depends on what trade-offs you're willing to accept.

        Cross platform Obj-C? You mean with GNUStep? I have never used it. Have only written Obj-C in Xcode. As far as memory management, C++ has smart pointers, including one that does reference counting. Why would the performance be better with Obj-C?

        Although my experience with Obj-C is more limited I find it more painful to use than C++.

      • Re: (Score:2)

        by Dog-Cow ( 21281 )

        I take it you've never worked on an app with a well-defined logic layer. Apple writes a lot of C++ themselves, and they're not concerned about portability beyond OS X and iOS.

  • Good grief. (Score:3)

    by engineerErrant ( 759650 ) on Monday May 11, 2015 @11:07PM (#49670489)

    FYI, I'm an iOS developer who uses a mix of languages, including Ob-C, every day. My coworkers and I met Swift with a mildly positive reaction - it's a decent, if imperfect, effort. It's not the second coming of Christ, but it definitely isn't a bad thing to try to modernize some of Ob-C's age-related shortcomings. The notion that we'd re-write code just to use it is utterly laughable, but we could certainly see ourselves using it to start a new app, or maybe at our next jobs.

    The OP, though, sounds like a marketing intern wrote it. To add a little historical perspective: our apps are a riotous mix of C and C++ (for Android portability) and Ob-C. We chose to do it this way, within the last 3 years, so this is not a legacy issue. Both C++ and Ob-C were, at one time, meant as "replacements" for C, and we know how that turned out.

    Swift may very well become the preferred language over Ob-C within, say, 5 years, for Apple-specific development. But the breathless "it'll replace C!" rhetoric is just silly. Over the coming decades, C will surely fade, but it will be replaced by other, newer, even more amazing tech, not just Swift.

  • So, mature, third-party, solid, stable, best-in-class, tried-and-true libraries that are the standard foolproof way to do "X" (choose from many "X"s) will all re-write themselves from C or C++ to Swift, and then keep themselves in sync with the mainline library, right?

    C and C++ will continue to be used in iOS apps for the same reasons that so many (of the better...) Android apps color outside of the approved Java lines and use C/C++ using the NDK.

  • And we know from experience that WHENEVER somebody uses terms like "language <XYZ> is the future", it is inevitably baseless speculation, and often rests on the false belief that some single programming language, or any single technology for that matter, can actually be the "best" one.

    Brooks said it best, There is No Silver Bullet [worrydream.com]

  • Predictions are like assholes; everybody has one.

  • I just can't decide on which loosing horse I should all my money!

    Jokes aside, anyone who knows a little bit about the history of Apple should be careful not to put too much efforts in one of their 'projects'. At least develop the core of your applications in C or C++ and use the proprietary technology just for GUI glue code. Unless we're talking about another fart app that requires zero know-how and programming effort anyway.

  • Swift for the system programming? (Score:3)

    by ThePhilips ( 752041 ) on Tuesday May 12, 2015 @06:26AM (#49671701) Homepage Journal

    People keep bringing up the Swift in context of system programming, but so far I haven't seen any concrete info about features of the language which make it even suitable for the system programming.

    The thing is, even C++ was/is used for system programming, but its C++-ness is so castrated that it is hardly can be called C++ anymore.

    I personally do not see any reason to replace C with another language, which I can't use to its fullest. On top of it, lots of C extensions are needed to make the system development efficient: code/data section assignment, untyped/unchecked memory access, memory/IO barriers, assembler intrinsic. None of that is part of C standard - all of it are vendor/compiler extensions. While Swift documentation is devoid of the similar features.

    P.S. If Apple folks want to push the Swift into the embedded area... Good luck. Even C++ still struggles. Higher-end embedded system require proof of validity and literally all of the solver software is C-only. Most static/dynamic code analyzers - C-only too.

Slashdot Top Deals

If all else fails, lower your standards.

Close