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.
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!
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
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.
@technicated Great stuff!
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.
My concerns with such an approach is fragmentation of the language. The standard library in swift is far more crucial than in most other languages due to fundamental types getting in the standard library rather than defined by the compiler. Building that as a subset of the existing library in tree would be something that would be preferable to maintain across all platforms. In order to ensure future work does not break the model and features are properly supported would mean that ideally the library should also be split in Darwin which I feel would be unlikely to happen.
Personally I don't think that's necessary. Even with less-minimalist additions like
CollectionDifference and the proposed
DiscontiguousSlice APIs, the standard library is still just fundamental types and generic algorithms/data structures. The system requirements are still very barebones (you need dynamic memory allocation... and that's about it?).
Embedded platforms (and WASI right now) are usually statically linked, so anything you don't need in the standard library/runtime should get stripped anyway. There was a talk at the recent LLVM conference that suggested we might be flagging too many things with
LLVM_USED and preventing DCE. I've inspected some built WASM files (which, again, are all statically linked) and they are full of runtime code I would expect to have been stripped, so there may be something to that - a simple
print("hello, world") results in a >9MB binary.
If we can rely on DCE to remove things we don't use, and things in the standard library remain as platform-agnostic as they are, I don't see a need to introduce a "minimal" subset of it.
Right—in an ideal world, a reduction in
@llvm.used by the Swift compiler would make it easier to avoid pulling in all the Unicode dependencies if you don't explicitly reference them. But even once that is resolved, I think that may be a bit optimistic when it comes to strings, since Unicode functionality is woven so intricately through their internal implementation and their APIs in their current state.
For example, many embedded users—or even regular Linux users not doing significant text processing—may not want the overhead of supporting anything other than ASCII strings. To avoid that overhead with just DCE, they'd need to make sure that nothing that they do ever touches a code path that might involve grapheme breaking, or normalization, or any other property queries—so that means using the
Character type and related APIs are out, and also string comparisons, to name a couple very basic ones.
I'm sure that
String could be refactored to better isolate ASCII-only behaviors, and a combination of that and user caution could achieve the desired goal—but I have no idea what the amount of effort involved in that would be.