Please create an account to participate in the Slashdot moderation system


Forgot your password?
Programming Apple

Apple Announces New Programming Language Called Swift 636

jmcbain (1233044) writes "At WWDC 2014 today, Apple announced Swift, a new programming language. According to a report by Ars Technica: 'Swift seems to get rid of Objective C's reliance on defined pointers; instead, the compiler infers the variable type, just as many scripting languages do. ... The new language will rely on the automatic reference counting that Apple introduced to replace its garbage-collected version of Objective C. It will also be able to leverage the compiler technologies developed in LLVM for current development, such as autovectorization. ... Apple showed off a couple of cases where implementing the same algorithm in Swift provided a speedup of about 1.3X compared to the same code implemented in Objective C.'" Language basics, and a few worthwhile comments on LtU.
This discussion has been archived. No new comments can be posted.

Apple Announces New Programming Language Called Swift

Comments Filter:
  • by Shag ( 3737 ) on Monday June 02, 2014 @08:25PM (#47151113)

    They've already got LLVM and Clang, no? Or did you mean better than those?

  • by Anonymous Coward on Monday June 02, 2014 @08:25PM (#47151119)

    Closures are already in Objective-C, the call them blocks, they have be really usefully, in dealing with multithreading they have been especially usefully.

  • by Ecuador ( 740021 ) on Monday June 02, 2014 @08:36PM (#47151195) Homepage
    I mean, there is already a swift programming language []. Yes, it is not popular, but when you decide on a name for your language don't you at least google it first? Is "swift" so unbelievably cool that a name collision (even with a "small" entity) does not matter? But, yeah, it is Apple we are talking about, they probably invented the word "swift" which people and companies like SUZUKI have been copying for other uses here and there...
  • by shutdown -p now ( 807394 ) on Monday June 02, 2014 @08:37PM (#47151203) Journal

    And which things have the 'potential to modify' the length of an array? Implementation defined?

    It's defined by the operations on the array. Basically, appending, inserting or removing an element would do that, but subscript-assigning to an element or a range will not.

    Fortran 90+ had it right. You just say for each argument whether the intent is data to go 'in' (can't change it), 'out' (set by implementation), or 'inout', values go in, and may be modified.

    Funnily enough, they do actually have in/out/inout parameters in the language.

    Note however that the story for arrays here does not apply only to parameters. It's also the behavior if you alias the array by e.g. assigning it to a different variable. So it's not fully covered by parameter passing qualifiers.

  • by Anonymous Coward on Monday June 02, 2014 @08:38PM (#47151207)

    Yes, Swift itself does not have the baggage of C just like Python does not have the baggage of C. The fact that both languages can interoperate with C does not change that.

  • by Anonymous Coward on Monday June 02, 2014 @08:43PM (#47151241)

    What possible application could ever require GDB as a dependency?

    LLDB is a far superior debugger anyways.

  • by Proudrooster ( 580120 ) on Monday June 02, 2014 @08:55PM (#47151323) Homepage

    Ok, you guys are too slow, I RTFA and downloaded the iBook. So far, I am very much liking the SYNTAX, especially OBJECTS and FUNCTIONS, they even brought the LET keyword in from BASIC. SWIFT will make programming Apple products much easier for the C loving syntax crowd, from what I can see. Ahhh... what a breath of fresh air. Code snippet below of creating an object and exercising it. I feel bad for those that suffered through Objective-C.

    “class Square: NamedShape {
            var sideLength: Double

            init(sideLength: Double, name: String) {
                    self.sideLength = sideLength
                    super.init(name: name)
                    numberOfSides = 4

            func area() -> Double {
                    return sideLength * sideLength

            override func simpleDescription() -> String {
                    return "A square with sides of length \(sideLength)."
    let test = Square(sideLength: 5.2, name: "my test square")

    Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. []

  • by Anonymous Coward on Monday June 02, 2014 @09:06PM (#47151411)

    There's not really a trade-off. It's just newer. Variable types can be inferred statically using unification (which is fast and actually more expressive than manually typed languages). Standard ML has done it for many years.

    Same with forcibly initialized values. Means you don't need to check pointers ever. Basically the same as references in C++.

    Bounds checking is rarely needed. Again, I point to Standard ML; here, instead pattern matching and higher order functions are used. This is basically what Swift does with closures and the map operation. If you look at the fold operations of all Standard ML types (that's basically the inspiration for the map-reduce paradigm), it is obvious that no bounds-checking is necessary, and iterating over an entire structure is almost always what you do with a data-structure (aside from initialization), and the only operation where you access the structure many times and would have an overhead for bounds-checking.

    Memory seems to be managed using ref-counting, which is similar to auto_ptr in C++. Barely any overhead (a zero-check on deallocation, which can even be biased towards branch-predicting that no deallocation needs to take place).

  • by Kesha ( 5861 ) on Monday June 02, 2014 @09:16PM (#47151479) Homepage

    There is VLC
    There is CMake
    There is my project -- []
    There is Sorenson Squeeze -- []
    I am sure there are others

  • by Guy Harris ( 3803 ) <> on Monday June 02, 2014 @09:16PM (#47151483)

    No this is NOT a troll, please read.

    A claim of cross-platform is one thing. But in practice I know of no significant apps using Qt that exist in the wild that work on OS X.

    Please provide a link to any mainstream working application for Mac OS X that uses Qt.

    $ otool -L /Applications/Google\\ Earth
    /Applications/Google Earth:
    @rpath/libgoogleearth_free.dylib (compatibility version 0.0.0, current version 0.0.0)
    /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0)
    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 155.0.0)
    @rpath/QtCore.framework/Versions/4/QtCore (compatibility version 4.7.0, current version 4.7.4)
    @rpath/QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current version 4.7.4)
    @rpath/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.7.0, current version 4.7.4)
    @rpath/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.7.0, current version 4.7.4)


    I don't know of a single one because Qt's support for XCode is incredibly poor.

    Do you have to use Xcode, the IDE, to develop OS X apps? Or by "Xcode" do you mean "Xcode the IDE, plus the command-line tools"?

  • by StikyPad ( 445176 ) on Monday June 02, 2014 @09:24PM (#47151527) Homepage

    Whatever source compatibility existed before Swift (and the degree to which that exists is surely debatable), it was not removed by Swift. Objective-C, C/C++, and Swift can coexist in the same project. I believe they can even coexist inline, which makes me shudder to think, but there it is. Still, you could ostensibly have a UI in Swift and your core business logic in C, if your architecture is solid. (Obviously YMMV, and there are bugs to be discovered, to be sure.)

  • by Anonymous Coward on Monday June 02, 2014 @09:39PM (#47151603)

    So then install GDB. There is no reason to stop supporting Mavericks because it doesn't come with GDB preinstalled.

  • It doesn't use Metro's libraries.

    Anything that doesn't use the Windows Runtime API (what you call "Metro's libraries") will not be approved for the Windows Store and will not run on Windows RT tablets or Windows Phone 8 smartphones.

  • I was under impression that all new windows "apps" had to be written in C# against a new SDK that has neither binary nor source compatibility with Win32/posix/C/C++. I'd be glad to be wrong, but that's what I've seen so far.

    Only Windows Phone 7 and Xbox Live Indie Games required C#.* C++ works on Windows Phone 8 and Windows RT, though they do require use of the Windows Runtime API. For actual Windows on x86, you can continue developing desktop applications without having to deal with Windows Runtime (the "Metro" crap).

    * In theory, they required verifiably type-safe CIL compatible with the .NET Compact Framework. In practice, they required C#, as standard C++ is not verifiably type-safe, and DLR languages require functionality not in .NET CF.

  • by perpenso ( 1613749 ) on Monday June 02, 2014 @10:35PM (#47151895)

    Good bye source compatibility. We hardly knew ye.

    I have absolutely no compatibility problems. I strictly use objective-c for only user interface code. The core functional application code is written in c/c++. I have multiple iOS/Android apps whose core code is shared and can even be compiled with a console app under Mac OS X or Linux, I use this for regression testing and fuzzing. A headless Linux box in the closet exercises this core code. Similar story for Mac OS X and Windows.

    Swift code can replace objective-c code and it matters little to me. Has zero impact on other platforms I target.

    Admittedly I've ported other people's code between Windows, Mac and Linux for years and written my own code for Windows, Mac and Linux for years and as a result I am extremely aggressive about separating UI code from functional code.

    For those people using some sort of cross-platform wrapper for their project, if it supports Mac OS X objective-c it will probably support Swift. Even if it takes time for the wrapper developers so what, the use of Swift is entirely optional.

  • by Anonymous Coward on Monday June 02, 2014 @11:26PM (#47152185)

    Wasn't a hard search. Adobe Photoshop Album is in there, Google Earth is in there too.

    From a more personal experience I helped create the windows port of Scrivener (very popular mac program written in Objective-C). The windows-port work was done in Qt/C++ and I did 90% of my development on a mac. And unless you were familiar with the program you would have a hard time picking which was the objective C version and which was the Qt version when they ran side by side on a mac.

    I'm not sure what the problem with XCode support is because I didn't use XCode. I didn't need to. I didn't want to. But then over the last ten years I've worked almost equally over the three major operating systems with a weighting to Linux.

  • by macs4all ( 973270 ) on Tuesday June 03, 2014 @01:45AM (#47152575)

    Apple has always been hostile to unified look on their platform.

    You do realize, of course, that you are talking about the company that literally wrote the book [] on good, consistent UI design, right?

    The above, linked pdf copy dates from 1995 (the earliest actual copy I could find in a 2 minute search), but Apple first published their most-excellent HIG manual on or around 1985 [], before most slashdotters were even born.

    Now, get off my lawn!

  • by ljw1004 ( 764174 ) on Tuesday June 03, 2014 @01:50AM (#47152599)

    Are you sure about the "metro"? Name is dead, but I was under impression that all new windows "apps" had to be written in C# against a new SDK that has neither binary nor source compatibility with Win32/posix/C/C++. I'd be glad to be wrong

    You're wrong! You can write Windows Store apps in C++ just fine. This C++ can use win32, posix, STL etc just fine. (however, all apps run in a sandbox, so some win32/posix functions aren't as powerful as normal, e.g. the sandbox doesn't let a Windows Store app enumerate files on the hard disk outside of the files it's allowed to touch).

    You can also write Windows Phone apps in the same C++. So a mobile app developer could write their core in posix platform-neutral C++, and have it portable across Android+iOS+Windows. I know a few who do.

    Of course posix doesn't have anything to do with windowing systems or touch, and win32 APIs (e.g. gdi32.dll, user32.dll) don't apply to windows store or phone apps since they don't have GDI or the traditional windowing system. So your C++ code will invoke new WinRT APIs to access the new functionalities. WinRT is perfectly compatible with posix/win32 APIs. Indeed, for some functionality (e.g. audio), you're REQUIRED to use win32 APIs because they're not exposed in WinRT.

    Here's some example code that shows how you'd mix the new WinRT APIs to get hold of sandbox-specific stuff, and then interop with traditional posix APIs. It also shows how the asynchronous nature of WinRT APIs combine with the synchronous traditional posix APIs:

            auto f1 = Windows::ApplicationModel::Package::Current->InstalledLocation;
            create_task(f1->GetFolderAsync("Assets")).then([this](StorageFolder ^f2)
                    create_task(f2->GetFileAsync("Logo.scale-100.png")).then([this](StorageFile ^f3)
                            auto path = f3->Path;
                            FILE *f = _wfopen(path->Data, L"r");
                            byte buf[100];
                            fread(buf, 1, 100, f);

  • by perpenso ( 1613749 ) on Tuesday June 03, 2014 @01:59AM (#47152629)
    Here is a Mac OS X GUI app with a window and a button implemented in objective-c (main.h, AppDelegate.h and AppDelegate.m). The button handler calls C code (Work.h and Work.c) to do some work. Note that if C++ code had been used then AppDelegate.m would have been renamed to .mm so that Xcode would compile it as Objective-C++, necessary to link properly against the C++ code it uses.

    //  main.m
    #import <Cocoa/Cocoa.h>
    int main(int argc, const char * argv[]){
        return NSApplicationMain(argc, argv);

    //  AppDelegate.h
    #import <Cocoa/Cocoa.h>
    @interface AppDelegate : NSObject <NSApplicationDelegate>
    @property (assign) IBOutlet NSWindow *window;

    //  AppDelegate.m
    #import "AppDelegate.h"
    #include "Work.h"
    @implementation AppDelegate
    - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    - (IBAction)buttonPressed:(id)sender {

    //  Work.h
    void some_work(void);

    //  Work.c
    #include <stdio.h>
    #include "Work.h"
    void some_work(void) {
        FILE *fp = fopen("/tmp/work.txt", "w");
        if (fp != NULL) {
            fprintf(fp, "Hello World\n");
  • by shutdown -p now ( 807394 ) on Tuesday June 03, 2014 @02:47AM (#47152763) Journal

    You completely miss the point.

    Regarding immutability, it's not about an array of constants. It's about an immutable array - as in, an array which has its content defined once, and not changed afterwards. They actually do use the term "immutable" for this, and this is what it means in any other language. It's also what it means in Swift - for example, an immutable dictionary cannot be mutated at all, neither by adding or removing elements to it, nor by changing a value associated with some existing key. The only special type here is array, for which immutability is effectively redefined to mean "immutable length, mutable contents" - which is a very weird and counter-intuitive definition when the word "immutable" is involved (e.g. in Java you also can change elements of an array but cannot add new ones - but this is the rule for all arrays in Java, and it doesn't call that "immutable"). The fact that there's no way to have a truly immutable array is just icing on the cake.

    And they don't pass collections by reference. They say that value types are passed by value (duh), and that both dictionaries and arrays are value types (unusual, but ok). But then they completely redefine what copying an array means, with a very strange copy-on-write semantics whereby they do implicitly copy them if you touch them "in the wrong way" (e.g. by appending an element), but not if you touch them in the "right way" (e.g. by mutating an existing element). Again, this magic is utterly specific to arrays - for dictionaries, they behave like true value types at all type, and use full-fledged copy-on-write under the hood to avoid unnecessary copies - so if you "touch" a dictionary in a way that mutates it, it makes a copy, and it doesn't matter how you do so - by inserting a new key-value pair or by changing a value for an existing key. Not only this is very much non-orthogonal (why make copying of arrays and dictionaries so different?), the behavior that's defined for arrays just doesn't make any sense in distinguishing between various ways to mutate them.

  • by Carewolf ( 581105 ) on Tuesday June 03, 2014 @03:42AM (#47152899) Homepage

    Take a simple one from Mac versus Windows: On the Mac, in a dialog box, the default button is always the right-most button. So you have a dialog box that says, "Are you sure you want to do this?" and the right-most button would say, "OK" and the button to the left of it would say, "Cancel." On Windows, the default "OK" button would be on the left with the "Cancel" button the right of it.

    Oh, stop trolling. You have obviously never used Qt, it will automatically fix the order of the dialog buttons for you. You can even launch the same application under GNOME and get one order, and under KDE and get another. It is controlled by the widget-style it uses. And it does more than that, it also matches the reading direction of the language you are using so that it reverses for Hebrew, Arabic or other right-to-left languages.

    There are things that you need to handle yourself in a crossplatform application, but that is not one of them.

Do not underestimate the value of print statements for debugging.