stricks VS swift

> I was thinking about Simple Dynamic Strings but I like this better.

Oh! here's my chance to plug https://github.com/alcover/stricks ! It follows the same principle as SDS (i.e user-facing type is char*) but is much faster (see bench) and frankly nicer to read through.

Not as feature complete, though.

Mine is also variable (see https://github.com/alcover/stricks/blob/main/src/stx.c). Maybe they switch more often that necessary ?

The threads were very interesting. I got back to work and it's time to talk speed ! https://github.com/alcover/stricks#speed

Amuse yourself, https://github.com/apple/swift/blob/main/docs/Runtime.md

Original Returnless Expressions PR

There is ongoing work that you can mix Swift and C++ code more or less directly, see here.

The Swift community came up with a couple of implementations of Either — a generic enum that carries one of 2 types associated with it (here, here, and here). There has been a discussion about adding Either to the Standard Library. Still, it seems we’re not going to have it in the foreseeable future because adding disjunctions (logical XORs) in type constraints is a commonly rejected evolution proposal. Funny enough, Apple has an internal implementation of Either in their standard library, but they are not sharing it with us ¯\_(ツ)_/¯

They are exactly the same except for when they're not.

(On 64-bit) Rust very naively has two 64-bit integers for the strong and weak count, Swift packs them into only one. Swift also packs in several extra flags for various things [0].

These flags mean that retain/release (increment/decrement) is actually an atomic compare-and-swap instead of a fetch-add. Allegedly performance issues with this were fixed by the hardware team, just, optimizing CASes better.

Swift also has to interop with ObjC "weak" pointers which have move constructors because their address is registered with a global map which is used to null them out when all strong counts go away, but I don't think this changes the design much when not using them.

Swift ARC is built into the language and a huge amount of the compiler's energy is dedicated to optimizing it. This is why it's part of the calling convention (+1/+0), why there are special getter/setter modes with different ARC semantics, why many stdlib functions are annotated with "this has such-and-such semantics" and so on.

Swift ARC is also very pervasive, as basic collections are all ARC-based CoW, all classes are ARC, and I think existentials and implicit boxes also go through ARC for uniformity?

ARC is also why historically Swift gave itself fairly extreme leniency on running destructors "early" based on actual use [1]. Eliminating a useless +1 can be the difference between O(n) and O(n^2) once CoW gets involved!

By contrast in Rust it's "just" a library type which you have to clone/drop (increment/decrement) manually. It doesn't do anything particularly special, but it's very predictable. The existence of borrows in Rust lets you manually do +0 semantics without having to rely on the compiler noticing the optimization opportunity, although you do need to convince the borrow checker it's correct.

[0]: https://github.com/apple/swift/blob/3b00177f768b630a8f7a1135...

[1]: https://forums.swift.org/t/a-roadmap-for-improving-swift-per...

Note that the screenshot you shared is from an old (and AFAICT abandoned) port of Swift based upon MinGW. You should look to https://swift.org for the official releases for Windows which are more current.

`Array` is defined in the Swift standard library, but the compiler knows about the type directly, and also recognizes various @_semantics("array.blah") annotations that appear in the standard library source code.

https://github.com/apple/swift/blob/main/stdlib/public/core/...

It's written in C++ although there is some Swift in it now [1]. The compiler doesn't depend on Foundation though.

[1] https://github.com/apple/swift/tree/main/SwiftCompilerSource...