Swift compiler annoyances

Question

I wonder who else has trouble with the new Swift compiler. I know its "brand new" (but according to Apple it's not beta) but to me it feels like a late alpha version. Apple is (one of) the most valuable companies in the whole world. I can't understand that this company places a product which is not only far from perfection but feels more like a PITA (I know it could be worse, I'm not talking about Mickeysoft). So here are my "favorites":
Source Kit crash: The last release tells that this has been improved. Well, before it crashed every minute. Now it's only every 2 minutes. My console log is full of source kit crash logs. Most annoying: it blinks the crash message on screen while BBOD. Time enough for a couple of --- sigh
Auto completion: Either it does not work at all (se Source Kit crash) or it takes too long to complete ("come on, I know you know what to complete" - argh) or it suggests rubbish (want the parameter list after a function? Only in 10% of all cases).
Compiler error messages. Most times the compiler only tells 2 or 3 errors before it starts with 10 more after they are corrected. But what's really annoying is the quality of the messages. Let alone the identification of the error position (that tiny caret). What does it want to tell with "Type () does not conform to (L$x...)" [I know, meanwhile...]
Most Obj-C NS* methods return AnyObject. You need to add "as NS<whatever>" in order to use it properly.
NSCoder.decodeIntegerForKey is really a head banger. Swift has this nice 64 bit Int. But here you have to use Integer. If you use Int you get a 32bit integer. Did the sleep in the QA??
Now some concrete failures:The following results in "too complex expression" - lol
  struct KV { var count:Int }
let keysAndValues = KV(count:10)
let keyLengths = 10
let valueLengths = 5
var whereClause:Any?
let size =  keyLengths + valueLengths*2+1 + 100 + whereClause == nil ? 0 : countElements(whereClause!)
size    
Hang Source Kit
struct Database {
  let db = [
    "oasis" : [
      "id" : "oasis",
      "sector_id" : "oasis",
      "name" : "Oasis",
      "type" : "planet",
      "image" : "planet_oasis",
      "xPos" : 170,
      "yPos" : 10,
      "spaceport" : true],
    "oasis_hub" : [
      "id" : "oasis_hub",
      "sector_id" : "oasis",
      "name" : "Oasis Hub",
      "type" : "station",
      "image" : "station_oasis_hub",
      "xPos" : 30,
      "yPos" : 70,
      "spaceport" : true
    "oasis_exit" : [
      "id" : "oasis_exit",
      "sector_id" : "oasis",
      "name" : "Oasis sector exit",
      "type" : "exit",
      "image" : "planet_oasis",
      "xPos" : -350,
      "yPos" : 0,
      "spaceport" : false
let db = Database()
Those were my "favorites". What do you think?

Answer 1

ThomasKilian wrote:
You got a point with radar. I was (well, I am) at a point where I got too frustrated in sending in bug reports at all. And yes, I also used lots of time to create a meaningful bug report. But what you said in mind I'll just file the minimum information needed. If "support requests more information" I still can spend that. But for sure it will again not take longer than 5 minutes then.
To be honest, I usually do my own bug triage first. If I feel like I would be embarrassed for using a Mac if some PC person saw the bug on my screen, then I will file a bug report. Otherwise, if I don't feel Apple is willing (or able) to fix the bug, I just won't bother. Sadly, I still file bugs on a regular basis with this system.
I was not aware that I could use another language than (now still) Obj-C and Swift. I will have a look into Eero.
Don't get too excited. While you can use any language you want, including C++, of course, and C# too I think, you still have to use Cocoa. I have no illusions about how well those cross-language runtime interfaces work in a real-world application. Even Apple has trouble with Swift. It is Cocoa that is the problem. Swift doesn't support exceptions because the anti-exception camp at Apple finally won the day. But one of the reasons they did win is because they were apparently in charge of Cocoa before. While Objective-C, and Eero, fully support exceptions, Cocoa does not. Matt Thompson has even announced the Death of Cocoa.
There there are whole bunch of other issues like Interface Builder, ARC, auto-layout, etc. that will keep developers under Apple's control. I would like to see a lot more independence. It was CodeWarrior, not MPW and Project Builder, that made the Mac. I think a little developer tool competition would be a huge benefit to both 3rd party developers and Apple itself, but I don't see that happening in today's world.