On the road to Swift 6

setjmp and longjmp are not safe to call directly from Swift, but using them as part of a runtime library that otherwise maintains the invariants Swift code (and the underlying OS) expects should be OK. If the coroutine library nevers resumes Swift code more than once at the same point (which could cause over-retain or -releases, or mess up OS stack maintenance), and doesn't ever try to "recover" by stopping execution of Swift code in a nested frame then resuming at an outer Swift frame as if an exception unwound the stack (which could leak memory, and also mess up OS stack maintenance), and it plays well with the invariants that some OSes and runtimes like Windows and Darwin libdispatch expect of execution contexts, then it shouldn't be any less unsafe to use with Swift than with other languages.


@Joe_Groff, thanks for dispelling doubts on using setjmp/longjmp. Hope this will put a full stop in this topic.

1 Like

Yeah, using setjmp/longjmp for cooperative green threads might be problematic for the OS, but it shouldn't specifically be a problem for Swift.

1 Like

I’ve mainly been working Elm the last few years and am just getting going with Swift. Are you using any packages that facilitate an Elm style architecture?

I’m building one for a client. If you’re looking for an open source package I recommend keeping an eye on PointFree.

1 Like

If Swift to Windows is not accomplished before the big depression that’s coming hits, consider the Swift project dead. Do a complete job on documenting how to install and build with Swift.

And please , while you are at it, make building with C libraries (other languages come later ) less miserable and non-dependent on Xcode.

dramatic much


I fail to see any connections between an economic depression and the state of Swift's development.


I don't know why you've suddenly decided to start trolling, but please find somewhere else to do it.

Anyway, the Windows port was started years ago and has made a ton of progress in the last few months.


On Linux, folks are building Swift applications using C libraries natively, without relying on Xcode, since Xcode doesn't run on Linux. There are Windows folks that are building with Microsoft C-libraries, but, it's still a bit rough, with lots of folks working hard to smooth out the rough edges.

How is working with C miserable given the different semantics of the two languages, especially pointers?


Interesting, I've been building one myself but it would be great if there was an open source project to contribute to (mine's at a fairly early stage). I take it you're referring to https://www.pointfree.co/ ?

Yes. @stephencelis might be able to tell you more about what they're up to.

@opsb We're gearing up to release an open source library that's been the culmination of a few years research and decently-scaled production use :) If you want to check it out before release please DM me and I can give you a preview while we polish the last few things.


It’s exciting to hear these goals articulated.

Regarding #1: In the teaching portion of my software life, Swift makes an appearance only if students choose of their own accord to do iOS projects, plus as a few-weeks-long object of study in the Programming Languages course.

We teach our intro / core computer science sequence in Python and Java, plus a smidge of C and x86 in the Systems course. Swift isn’t really even on the table for any of those core courses. Why? The top reasons are:

  1. Poor Windows support
  2. Poor Windows support
  3. Poor Windows support
  4. Poor Windows support
  5. Poor Windows support

Imagine this student: they wrote their first line of code a few weeks or months ago. They’re more comfortable with mobile than desktop interfaces; even file navigation using Explorer feels unfamiliar. They’ve never touched a command line. They’re feeling overwhelmed and intimidated by the firehose of new information. They harbor a terrible self-doubting voice in the back of their head that says, “Programming isn’t for people like you,” and they’ll believe that voice if they encounter enough frustration to confirm it.

When that student can install and use Swift without frustration on a Windows laptop of dubious vintage, then I could consider making a case for using it in our curriculum.

Regarding #3: I’ll echo others who hope to see generalized existentials on that list. While I recognize that they are often a misleadingly wrong tool that people might reach for too quickly without understanding, and recognize that the core team is resistant to adding them before the language has “all the things you really want instead of existentials,” the lack of them is a hard dead end in the language right now that has forced some ugly compromises in my code over the years. I do hope they get their due sooner rather than later.


It would be great if Swift 6 includes improvements for scripting. Specifically an easy way to import packages into a script, something similar to how it works in Python. I've seen there is a good proposal from @Rahul_Malik. Hopefully this is feature will be available soon.


I am mostly focused on iOS development with Swift, however I am extremely happy that it is expanding on other platforms / operating systems. It would be cool to make cross platform CLI tools without resorting to ruby or python.
@tkremenek What about Actors from the Concurrency Manifesto, is it something that would be investigated for Swift 6 or later down the road? I know async / await is something that a lot of people are excited about but Actors are not discussed as much here on the forums. I have been learning Elixir lately and I am impressed by the OTP framework.


I am so happy if the core team allow swift to make the android app. For example like flutter support android and ios app both. I want to suggest to core team make one language code base to export two apps android and ios.

It would be nice to program Android apps (and everything on every platform) with Swift. However, Swift is a general-purpose programming language, not a GUI tookit/framwork like Flutter. Swift already builds on Android, but it takes more than just the language to make an app.


You might want to check out https://github.com/flowkey/uikit-cross-platform which we’ve been using to share all our UI code between iOS and Android in production for the last couple of years


^ @vinod1988

Terms of Service

Privacy Policy

Cookie Policy