SwiftUI List performance

FInally figured a workaround of sorts. Xcode seems to be picking up on another SVN repository that I have that is completely unrelated to my xcode projects (it's in a completely unrelated directory). It is included in the list of repositories when I look at Preferences->Accounts. Nothing I could do would convince Xcode to ignore the repository (tried deleting the reposity from the account list, but it would just come back next time I restarted Xcode). Tried disabling the repo. No effect. Still rows of ?s on my source code.But then I tried removing the other repository (as in: removing the directory containing it - not via Xcode). I then fired up Xcode. This time it popped up a dialog at the beginning, saying:This workspace includes files from other working copies that are not checked out. Choose Check Out to select additional working copies. Choose Ignore to skip these working copies.If I then say Ignore - voila.. the problem is fixed!When I get a chance I'll experiment to see whether I c

Seems odd - even with deployment set to 8.3 it should list various simulators. What simulators do you have installed in Preferences?Try a new project using your choice of simulator and see what it does.Also, did you by any change rename Xcode or install it someplace atypical?◅▻

Hey TungstenT.I got it to run after the same steps you took. I had to change the iCloud Document Storage to App Groups also. (This is probably not related to your issue)Possibly obvious question, did you try a 'Clean'?My issue is getting the UI tests to run as they did in the WWDC15 videos :-( ('Cookies' keep getting adding to the list as 'can')Cheers,Mark

Seems to happen pretty often to me. Just happened now, I cleaned, rebuilt, uninstalled on watch and phone, reinstalled, rebooted the device, and finally, I managed to get it running by opening the Apple Watch app on my phone, going to the my app listed there and toggling Show app on apple watch off until it war removed. Then I toggled it back on, and after it reinstalled, it worked.I have yet to find a definitive way to get it working again when this happens to me, but I will let you know if I do. Just keep keep tinkering with it like I did above and you should be able to get it working (assuming it works in the simulator).EDIT: Just happened again to me. Toggling that option in the Apple Watch app didn't work this time. So I toggled it off, rebooted watch, toggled it back on and it worked.

Ok, I figured this out..In Xcode the Window menu, select Devices, also includes a list of Simulators. You can Add + ones that are not there.Works the same way in Beta 7.....

If you are trying to run the equvalent of 10 million operations per second, every second, then you're at risk of failing to meet your frame rate requirement, no matter what language you use. In that case, the choice of language (at least for that part of your code) is critical, and chances are you wouldn't use Sprite Kit at all. However, the more rational choice is to avoid running 10 million operations per second. (If nothing else, that sort of thing will kill battery life.)The numerical problem with your original analysis (I claim) is that you were assuming your app was otherwise idle, but you were sharing time with Sprite Kit. In fact, if you wrote the double loop as a simple test app in C++, it would be otherwise idle, because by definition you wouldn't be sharing time with Sprite Kit itself. If you want to microbenchmark and empty Swift loop vs. an empty C++ loop, you need to actually measure the elapsed time for the loop alone, not the frame rate. You'd also need to make sure the C++ compiler didn't opt

Thanks, this will work, but this approach will still not solve return the closure and clear it problem.If you want to return the closure and attempt to clear it afterward, you have to use a mid-layer wrapper, which is the same as you wrote shove all of this inside an object and manually clear it via the wrapper.However just as I said in the first post. I think it is somehow not elegant.One last thing I'd like to discuss is that although func foo() is defined globally, the calling context may not be global. For example, there is an object of a certain class which needs a function to do some calculation, in the lifetime of this object, it may generate a closure using foo(), returned along with the closure is some additional data just like Nested; when this object is dead, it no longer needs this closure and that addition data. There should be a more elegant way to perform this task without having to involve a mid-layer wrapper.

I’m not a compiler expert, but for statically dispatched functions/methods (and possibly dynamically dispatched internal methods), I imagine the compiler should be able to determine an unambiguous list of error types generated by all throw & try statements within the function body, and associate this as hidden type information. Similar to the explicit error type annotations that everyone seems to be foolishly requesting, but automatically generated by the compiler.There are a number of scenarios the compiler wouldn’t be able to infer (which is what I thought was meant by the compiler attempts to infer) such as public non-final object methods, function parameters on public functions/methods, and public protocols - in this case you would still require the `catch {}`I’m starting to think if this was ever part of the plan, the increased emphasis on protocols/protocol extensions killed it. There’s definitely a big gap left in terms of how possible error types get communicated to consumers.