Silver: Swift for .NET

“Silver” brings Apple’s Swift language to the .NET and Java worlds. It brings the language not the Cocoa libraries though. Sounds like they added exceptions to let Swift work with .NET or Java better. (Personally I think Apple should add exceptions too, but I know people at Apple really don’t like exceptions and use them just for a very limited set of errors)

Related Posts

  • 85
    Nick Lockwood has one of the best discussions of Swift exceptions I’ve found both in terms of design, problems and benefits.
    Tags: swift, exceptions
  • 63
    There were some big changes to Swift this week. The most surprisingly controversial one was the adding of “exceptions.” I put those in quotes because they are quite unlike traditional exceptions in C++, C#, Java or Python even though I’ve called them Pythonesque at times.[1. I think I called them…
    Tags: exceptions, swift
  • 44
    How to merge Apple Photos libraries. Unfortunately requires sufficient iCloud space.
    Tags: libraries, apple

3 thoughts on “Silver: Swift for .NET”

  1. Personally I think Apple should add exceptions too, but I know people at Apple really don’t like exceptions and use them just for a very limited set of error

    Part of the problem may be memory management. Exceptions tend to clatter back through the stack without so much as a by-your-leave, never mind meticulous retain/release. The main benefit of exceptions to developers is that handling them is completely optional. If you don’t care about them you don’t need to write any code to deal with them, and the program will simply halt with a basic error message and accompanying stack trace.

    Personally, I don’t have a problem with functions returning either a result or an error. Part of the problem thus far is Swift’s type system being unfinished and buggy, which makes that pattern all kinds of horrible and painful, but hopefully it’ll be fixed soon if not already in 1.2.

    The one thing that would be cool is if the compiler optionally allowed you to omit the subsequent pattern matching code. Error handling’s one of those things you often don’t care about during early development or quick-n-dirty scripting, so it’s a bit of a chore having to add that code every time just to get the thing to build and run. If the compiler could automatically promote unhanded error objects to permanent exceptions, it’d streamline the writing process while still ensuring runtime safety. The Swift compiler already automates memory management for you; why not rudimentary error handling as well?

  2. Yes, in C++ unwinding pointers in exceptions can be tricky. Although other languages such as Python seem to manage it quite easily. However ObjC, which had exceptions (which were I think at the compiler level just C++ exceptions) didn’t want you to use them in preference to NSError. However while NSError did somethings well it did other things in a very complicated way (IMO).

    Even if they don’t use C++ styled exceptions it’d be nice to have something that avoided all the if statements associated with checking NSError. It reminds me of all the horrible C styled checking of errors when using stdio. Surely in this day and age we can do better.

    1. > Even if they don’t use C++ styled exceptions it’d be nice to have something that avoided all the if statements associated with checking NSError.

      A nicer pattern matching syntax wouldn’t hurt. Especially if it includes shortcuts for returning the error straight to the caller or promoting it to a permanent exception.

      Language design is fun.

Leave a Reply

Your email address will not be published. Required fields are marked *