Ok yes, (though Docker complicates this), for Server-side Swift it's important for an application to work identically cross-platform (or at least on Linux/Mac) to avoid complications between your development and production environments. Though that's far from a solved problem with plenty of existing languages used on the server.
Are there other places? It seems there has been plenty of investment in Swift already even with Apple platforms being the only mainstream use-case.
It’s so exciting to be part of Swift’s community since Swift 3 (as my first programming language). It’s awesome how fast Swift became matured language and I would really love to help developing Swift as fast as I will get good enough to push some PRs!
Just looking at existing OS code from the last 40+ years (C/C++). OS/math/graphics/game/network/etc libraries could all be written in Swift from now on, or in a language with similar modern qualities (safety, clarity…). But that requires ubiquitous/unconstrained availability.
What I’m interested in are fixed-size arrays that are struct types that can be stack allocated (like the C array I mentioned). Is that what you’re suggesting? How would you achieve that with Swift 5?
Yeah, Swift isn't yet an option to replace ubiquitous low-level libraries. Realistically it'll still be a few years until that happens.
It would be fun to take further discussions about this in this thread about fixed size array hacks that I just created!
WASM stands for Web Assembly, which is a binary file format designed to be executed in web browsers.
There is actually a project to compile Swift into WASM. This is one way to target web browsers, but far from the only one.
Really exciting stuff! I'm really looking forward to improvements in concurrency and ownership in Swift. Also variadic generics will be a really welcomed addition to the Swift language!
@tkremenek, will improving the String API be part of the direction for Swift 6? Providing better ergonomics and high level support for regular expressions really has the potential to make strings much more powerful in Swift. Also, it would be nice to ditch the clunky and limited API of NSRegularExpression that as of now we have to depend on. This was laid out in the State of String: ABI, Performance, Ergonomics, and You! and the corresponding Swift Forums thread.
As a Swift compiler developer myself, it's hard to commit to doing this regularly, because it takes significant effort to distill compiler-implementation work down into digestible content, and of course work-in-progress can change significantly. Technical blog posts on swift.org require a lot of effort.
I feel like the Swift weekly brief does a decent job of collecting what's going on and pulling out the interesting tidbits from GitHub, Twitter, the forums, and other Swift gathering places. I'm sure they'd appreciate more help keeping the community informed!
All that said, I wrote up something about progress on the function builders implementation that's probably the kind of thing you're looking for.
Doug
Sorry, I didn't mean bi-weekly in depth blog posts. That would definitely take significantly more time and effort. While I appreciate the user detailed blog posts all I was suggesting was essentially the name of a feature/fix and roughly where it was in progress in the grand scheme of things. Nothing detailed, just really high level.
But thinking about it you are right in that it's probably very difficult to distil a lot of that work down to simple things that would actually make sense out of context. I did used to check out the weekly brief for a while, I'll make sure to check back more regularly and see what's going on there.
I'll definitely check that out, that's my next stop this morning, thanks!
Here!
Firstly, huge congratulations to the new core team members. I'm sad to see Dave stepping down, but I hope he'll continue to be active with the language.
One domain that I think is worth keeping an eye on is scripting. Scripts are interesting, because lots of programs start out as scripts. At the same time, Swift is a great language for scripting, because (especially on Darwin systems) lots of system functionality is exposed via Swift. If I have to resize a bunch of images - sure, I could download imagemagick, learn it's complicated command-line interface and fumble around with shell scripts; or, if I'm on a Mac generating images for the AppStore, I could use Swift and the much more pleasant CoreGraphics interface.
It's incredibly common to want to have scripts that perform some action or generate other images based an image's contents. It's really hard to do this without a language like Swift, and it's great because all your code is also written in Swift.
Also - scripts really favour brevity. Not so much in the names of functions and parameters, but in how much boilerplate you need to just get something done. Things like parsing command-line arguments should be way easier than they currently are. Which brings me on to Foundation.
I don't think Foundation has really worked to make Swift a pleasant language to use. Part of that is structural - it has a closed evolution process and is entirely controlled by Apple. The other part is technical - it tries to be a platform-abstraction library over things like sockets and files, but really it's a system library, because it's part of the OS on Darwin platforms. That means Darwin platforms get the worst compatibility story, with @available and fallbacks everywhere, and the inability to take advantage of new API (e.g. let's say we added a new command-line parsing API - it would be unsupported on all current versions of macOS). I think there is room for a library above Foundation, with a more radically-swifty API and independent versioning.
The original goal was, I think, that Apple platforms would have an optimised version of Foundation because they build Swift in to the OS. That can still be true, and it's great that Apple provides Swift-native generic types and protocols in their OS libraries, but I think the smarter option is to access those fast Foundation APIs via an intermediate library that can float and add new features. Something more like what ToolsSupportCore provides.
I'm very happy to hear that low-level systems haven't been forgotten about 
For Swift scripting you might find swift-sh and related utilities (command line parsing, dealing with paths, etc) by @Max_Howell1 to be useful. I've used them some with good results. Max is open to contributions that improve them or fix issues you run into.
I've seen it - it's a very cool project! That's definitely something I'd like to see in the official compiler for Swift 6. You could see this as a natural extension of our existing support for swift run --repl.
WASM support is more difficult than other targets due to WASM itself not being sufficiently mature to support Swift. In particular, they do not have support for threading nor do they provide stubs for the necessary compatibility. Getting proper support for WASM in ICU would actually unblock the path to enabling the use of Swift on WASM IMO.
Well, the progress with the Sourcekit-LSP was significant. I’m using Swift from VSCode on Ubuntu 18.04 quite a lot without issues. And most of the issues is resolved by building package. Also, LLDB plugin on VSCode works great with Swift. I‘ve made it working in vim but I’m no big vim user. You can follow for example this guide: https://medium.com/@pvzig/swift-development-with-visual-studio-code-on-linux-99cac3918582
ICU is a big challenge. Rust doesn't have this problem because it includes its own ICU data which is at least enough for the minimal things they support (case mappings, some character properties like is_whitespace, etc). I believe we want to do the same, but we use much more data for full internationalisation, normalisation, etc.
Yes, this is something which has come up a couple of times before. @Michael_Ilseman has thoughts on how to accomplish this. I think that a rather useful investment in this area (perhaps @Michael_Ilseman is willing to do this or perhaps help to accomplish this) would be to write up an approach and break down the path to achieving independence from ICU. This would not only reduce the complexity of our builds but also the build size and distribution size while making it easier to port Swift to embedded environments.
There are a limited number (though greater than perhaps strictly necessary) where we fall to ICU in the standard library, and explicitly enumerating them and providing some guidance on what possible approaches for them could possibly speed up our ability to cleave that dependency.
There have also been a number of "embedded Swift" efforts, which often don't need any sort of higher-level Unicode support at all. Another approach we might take would be to work on establishing a subset of the standard library that can made available on more limited targets.