I'm of the impression that Swift is reference counted, which, while technically a kind of GC, is also appropriate for low level / systems programming (which isn't to say that Swift is a good language for low level / systems programming; only that its memory management isn't the disqualifying factor).

You can make RC quite nice (I've written cycle collecting implementations before) but there's reasons why C++ programmers are encouraged generally to avoid shared_ptr and use unique_ptr whenever possible: harder to reason about or trace object lifetimes, and performance implications.

Now if the garbage collection was optional, and one could still freely heap or stack allocate and free, then, yes, I could see it. But I don't think that's the case w/ Swift, at least not last time I looked at it. It's also why Go is imho not a 'systems' programming language.

Swift has what you would call an ‘indecent’ RC design, then, because it doesn’t.

> and it usually plays havoc on L1 cache (by touching counts).

Swift (like Objective-C) can store the refcounts either inline or in supplementary structures, for performance.

> Now if the garbage collection was optional

In the common case, it practically is, as (most) value types will only ever live on the stack, or inline in another data structure.

Glad to hear that value types are optimized well.