It does reference counting, but it's not mark-and-sweep stop the world reference counting. It's as garbage collected as shared_ptr<T> and doesn't try to collect cycles. Feels a bit weird to put that under the same bucket as Java.

Any CS book on garbage collection algorithms worth its place on a good paper bibliography, places reference counting among the possible implementations of garbage collection.

What the common dev without compiler background knowledge calls GC is actually named as tracing GC on CS literature.

Academically, both reference counting (C++, Swift, some patterns in Rust) and tracing garbage collection (Java, C#) fall under the umbrella of garbage collection.

The important distinction, then, is obligate garbage collection. Can I write a substantial program that does, and needs, no garbage collection of any kind? In C++ and Rust, yes, trivially, every day.

The distinction matters because without obligate GC, you get the benefit of destructors (or in Rust, the Drop trait), and have the tool for resource management of every kind, usually written "}". Reference counting GC is rarely used in well-designed C++ and Rust programs, simply because there is rarely any need for it. Reliance on shared_ptr or ARC is recognized as a disease of forced Java converts.

This isn't true if you've actually seen production Rust code, but the point is irrelevant to the issue of swift being GC'd - it is.

Would be even weirder to put it in same bucket as Rust, which uses compile-time analysis to solve the problem.