I like the direction of this vision, especially the emphasis on modularity, currency types, clear layering, and moving platform-specific complexity lower in the stack.
My perspective comes from a long history of IP network architecture and design work, particularly in carrier, public-sector, and operational infrastructure environments. From that angle, I think this vision can open an even larger opportunity for Swift than client/server APIs alone: Swift can become a strong language for network control, infrastructure modeling, routing/security tooling, diagnostics, automation, and policy systems.
That opportunity depends heavily on getting the lower currency-type layer right.
One point I would like to reinforce is that the core IP currency layer probably should not stop at IPAddress.
For many applications, an address is the obvious primitive. But in routing, ACLs, interface configuration, RPKI validation, IPAM, DNS operations, peer configuration, summarization, diagnostics, multicast handling, and network automation, the unit of work is often not just “an address”. It is frequently an address with prefix context, a canonical network prefix, a delegated block, or a neutral CIDR range.
A useful IP currency model for those domains likely needs concepts along these lines:
AddressFamily
IPAddress<Family>
PrefixLength<Family>
IPNetwork<Family>
CIDRBlock<Family>
IPMulticastGroup<Family>
The important part is not those exact names. The important part is preserving the semantic boundaries.
For example:
IPAddress can represent concrete address bits with address-family and prefix context.PrefixLength can validate prefix lengths per address family.IPNetwork can represent a canonical network boundary.CIDRBlock can represent a neutral prefix-aligned range or delegation form.IPMulticastGroup can preserve multicast group semantics instead of inheriting unicast host/subnet/broadcast assumptions.AddressFamily can be a compile-time trait rather than a runtime tag, keeping IPv4 and IPv6 operations type-safe while still allowing mixed-family wrappers at API boundaries.
Those values are related, but they are not interchangeable. In this model, even an address-only spelling has prefix context. For IPv4, 192.0.2.1 is equivalent to the host address form 192.0.2.1/32. The difference is whether the caller needs to surface that prefix context or only access the address value.
192.0.2.1 // IPAddress — host address form; implied /32 for IPv4
192.0.2.1/24 // IPAddress — address with prefix context; host bits preserved
192.0.2.0/24 // IPNetwork — canonical network prefix; host bits zeroed
192.0.2.0/24 as delegated // CIDRBlock — neutral delegated range/block
224.0.0.251 // IPMulticastGroup — multicast group address; implied /32 for IPv4
Those examples may share address-family, parsing, formatting, and bit-manipulation machinery, but they have different meanings in real network software. Collapsing them too early into strings, socket addresses, or one generic address type makes higher-level code recreate the missing semantics repeatedly.
As one implementation data point, I have been exploring this shape in swift-cidr, a pure Swift CIDR math and IP currency-type package. The goal of that package is not to model the full transport layer or socket metadata. Its primary focus is CIDR-safe address-family modeling, prefix validation, canonical network calculation, containment, range/delegation semantics, multicast group/range modeling, and related IP math.
That experience has made one design boundary stand out: SocketAddress should probably be treated as an adapter/platform representation, not the central semantic IP type.
A socket address is important, but it carries platform and transport representation concerns. The CIDR layer should be able to exist below that. It should provide correct IP address, prefix, network, range, and family semantics without being shaped by sockaddr, NIO channel types, or backend-specific storage.
Another module can absolutely build the next layer: endpoint values, transport protocol metadata, socket adapters, SwiftNIO integration, Network.framework integration, and higher-level connection APIs. But those layers become cleaner if they can build on a small, correct, shared CIDR foundation instead of each reinventing address and prefix behavior independently.
Similarly, an address-only view of IPAddress is useful, but it is not enough for the systems side of networking. Operations such as containment, subnet traversal, summarization, prefix-range matching, multicast group-range validation, and policy modeling naturally belong to a network-aware model. If those concepts are left to each package to reinvent, Swift risks repeating fragmentation at the IP layer that this vision is trying to reduce at higher networking layers.
So my main feedback is:
The vision’s currency-type direction is right. I think the foundational IP layer should be broad enough to cover real infrastructure work: addresses, prefix lengths, canonical network prefixes, neutral CIDR ranges/delegations, multicast group/range semantics, and clear adapter boundaries for POSIX/NIO/platform interop.
That would give Swift packages a stable vocabulary for addresses and prefixes across configuration files, JSON APIs, persistence, routing/security tools, server frameworks, diagnostics, and network automation without forcing every package to rebuild CIDR semantics on top of strings or socket-shaped types.
