Nope, no issues here.

I'm stuck in Swift land for at least the next week, so expect a lot of moaning and groaning. There's for sure some parts that I like about it, if they had a version with maybe 1/4 of the features (i.e. needless complexity) I might actually say I'd enjoy using it.

Yesterday's Swift week highlight was spending at least an hour trying to find the right annotations to tell the compiler/concurrency stuff what a couple methods do threading wise. Turns out I had the right combo from the get go but it’s broken in both Xcode 26.2/4 and fixed in the .5 beta. Couldn't tell in older Xcodes because Apple blocks old Xcodes from running in current OSes for "reasons”.

Swift's concurrency approach is emblematic of its complete lack of pragmatism. Runtime sees hey I think this code is running in the wrong thread (or context if you must) what do I do? Warn and ignore, because it's probably OK 99% of the time, nope. Warn and correct, because you have enough info to infer what is probably needed, nope. How about crash 100% of the time, yep, that's the one.

@paul “warn and ignore” will get ignored by nearly every developer even those with good intentions (especially with the spam factory that is revealed in Console.app). Not sure if "warn and correct" is feasible, you'd know better than me since I nope’d out. Crashing unambiguously is almost always the best option since the developer can more easily find and fix the issue. As annoying as it is, it's 1000x better than some very rare bug that can't be reproduced and only manifests visibly minutes or hours after the problem and potentially corrupts user data along the way.