swift

They do! See https://github.com/apple/swift/blob/main/docs/LibraryEvoluti... You can also see an example of what a .NET integration with Swift ABI looks like here: https://github.com/dotnet/designs/blob/main/proposed/swift-i...

$ clang++ foo.cpp -o foo -framework Foundation -lswift_Backtracing also works, but dunno if that's "public API" $ codesign --force --sign - --entitlements entitlements.plist foo https://github.com/apple/swift/blob/main/docs/Backtracing.rs... $ SWIFT_BACKTRACE="enable=yes" ./foo Very cool!

> Perhaps biggest of all Swift doesn’t need a runtime like Obj-C Swift most certainly has a runtime: https://github.com/apple/swift/tree/main/stdlib/public/runti... And most or all of it is written in C++, not Swift last I checked. Whenever you see a `_swift_fooBarBaz` symbol in a stack trace, that's the runtime.

Two examples from Apple: • The Swift Programming Language: https://github.com/apple/swift • FoundationDB - the open source, distributed, transactional key-value store: https://github.com/apple/foundationdb

You can do the same thing the other way around - https://github.com/apple/swift/blob/main/docs/Android.md.

Codable (along with other derived conformances like Equatable, Hashable, and RawRepresentable) is indeed built in to the compiler[0], but unlike Serde, it operates during type-checking on a fully-constructed AST (with access to type information), manipulating the AST to insert code. Because it operates at a later stage of compilation and at a much higher level (with access to type information), the work necessary is significantly less. (It's difficult to compare Serde and Codable in a way that isn't apples-and-oranges, but at the very least, Codable makes use of information that the compiler has done, and has already needed to do anyway; there's very little manipulation it needs to do to achieve its aims.) With ongoing work for Swift macros, it may eventually be possible to rip this code out of the compiler and rewrite it as a macro, thou

> Primary-file mode's advantages are that the driver can do incremental compilation by only running frontends for files that it thinks are out of date, as well as running multiple frontend jobs in parallel, making use of multiple cores. Its disadvantage is that each frontend job has to read all the source files in the module before focusing on its primary-files of interest, which means that a portion of the frontend job's work is being done quadratically in the number of jobs. Usually this portion is relatively small and fast, but because it's quadratic, it can easily go wrong. The addition of batch mode was specifically to eliminate this quadratic increase in early work. One example that would improve the above: replace module imports with file specific imports, including within the module itself. You could also make a case for operator

> There's not even anything technically interesting about the language It's a modern statically compiled language with complex generics, that supports providing a generic interfaces in libraries with retaining ABI compatibility. Which no other modern "system" language supports. That's fairly technically interesting to me. > We have so much more than that and you just went with reference counting Like what? The options for memory safe shared ownership are refcounting or GC. Assuming you're talking about rust, that's just C++: object lifetime is lexical, and if you need it to last longer you have to use Arc/Rc/shared_ptr. The purpose of the lifetime and borrow checkers is to ensure exclusive access, and reduce the copy/destruction churn that you get from the C++ model (a hypothetical C++ that only allows the use of unique_ptr instead of raw

Happily Swift has interop with C, and they're working on actual C++[1], which would be a lot of wasted effort. The question is very simple: Swift is meant to be a safe language, how feasible is that if a large chunk of the core types and runtime are implemented in C, C++, and Objective-C/C++? Migrating to Swift is the obvious and sensible step, unless you propose re-implementing them in yet another language? [1] https://github.com/apple/swift/blob/main/docs/CppInteroperab...

Nope it doesn't work that way for swift, stuff has to repeat on multiple cores per file within a single module, leading to being less compute efficient the more cores you add, unless you force everything into a single thread with WMO mode, but then you have manually manage your build graph very carefully to stay compute efficient. It could've changed since I've last looked, but there are still things like that are lurking around. https://github.com/apple/swift/blob/main/docs/CompilerPerfor...

There are some interesting approaches in Swift: https://github.com/apple/swift/blob/main/stdlib/public/Obser... https://github.com/apple/swift/blob/main/stdlib/public/Obser...

I think you're referring to the SR-103 issue: https://github.com/apple/swift/issues/42725

That is correct. Like Objective-C the compiler statically removes ARC when it can prove it doesn’t need it (or when you annotate it because where you’re getting it from is manually managing and giving you ownership of the reference). So within a function or cross function with LTO (although it looks like swift doesn’t yet have LTO [1] so I’m not sure about cross-module optimizations). > When receiving a return result from such a function or method, ARC releases the value at the end of the full-expression it is contained within, subject to the usual optimizations for local values. Quote from [2] (section 6 has the full details about optimizations). I believe [3] might be the compiler pass. There actually is some elision that happens at runtime if you install an autoreleasepool if I recall correctly. I did actually work at Apple so that’s w

I've always heard of the "Swift elides reference counts" statements but I've never seen it substantiated. I don't claim to be a Swift GC expert by any means, but the impression I get from the two Swift GC papers I've read [1, 2] is that Swift has a very simple implementation of RC. The RC optimization document (albeit the document is incomplete) [3] also doesn't give me the impression that Swift is doing much eliding of reference counts (I'm sure it is doing it for simple cases). Do you have any links which might explain what kind of eliding Swift is doing? EDIT: The major RC optimizations I have seen which elide references are deferral and coalescing and I'm fairly certain that Swift is doing neither. [1]: https://dl.acm.org/doi/abs/10.1145/3170472.3133843 [2]: https://doi.org/10.1145/3243176.3243195 [3]: https://github.com/apple/swift/b