The comments indicate these methods always return 0 because the data is not tracked in swarmkit. This could lead to incorrect filtering behavior when using the 'dangling' filter on swarm networks. Consider adding a more detailed comment explaining the implications of this limitation.

It looks like this is doing a lot of work to return a count, and the count isn't needed - a bool HasServiceAttachments function could just make the GetTableByNetwork calls n.Services makes, and return true as soon as it sees a non-empty result? (No need for unmarshalling, digging out ports, or grouping tasks by services.)

Maybe for a follow-up? But could make it a bool now - or, perhaps just change the name to make it clearer that it's returning a count, not the attachments?

Good call out on these; I wonder if we should start looking at replacing some of these operations with Iterators; in that case we could terminate early without already having paid the cost for collecting / constructing all the data, And for cases where we only need to know if "more than 0" attachments, can do something like;

// ServiceAttachments returns len(n.Services()).
func (n *Network) HasServiceAttachments() bool {
    for range n.ServiceAttachments() {
        return true
    }
    return false
}

We usually only have two groups of imports?

Yes, but: #50394

Oh! On topic of performance; this information had some implications as it was a breaking change and I think we even silently backported this change to the Docker EE releases (or had some tweak to make it configurable there) https://docs.docker.com/reference/api/engine/version-history/#v128-api-changes

The default was for docker network ls to collect all the same information as docker inspect would give, which included details for all containers and services attached. This brought down some UCP clusters, which (I think) was polling networks through Swarm V1, which meant; aggregate all networks, for all nodes in the cluster, which by default included all containers attached; that .... didn't work well with a cluster with a couple of thousand containers, which either resulted in out of memory, or the time to collect the information taking too long, causing UCP to consider the cluster to be down, and starting to kill nodes 😬

Fun discovery here that either I wasn't aware of, or forgotten; looks like Match is not just a "Match full name / id or prefix, but allows for regular expressions!". I'm not even sure if that's documented

Not even sure if that's fully working as expected; as it would to an exact match on a string that could technically be a regex (i.e., filtering on (foo|bar) would match an object literally named like that (we don't allow that for most objects, so probably not a real issue).

I think that means we're compiling the same regex for every network in the list while filtering (worse; could be multiple name2match theoretically, and those are not combined into a single regex) 🤔

Match as a name is definitely poorly chosen; even more ironic is that FuzzyMatch is then less "fuzzy" than Match() (and maybe should've been named MatchPrefix?). If the regex is not documented, possibly we could even use FuzzyMatch (or MatchPrefix if we decide to rename) to avoid the regexp.MatchString

I'm not even sure if that's documented

Looks like we documented the "observed behavior" (or at least, I have a vague memory of a PR updating the documentation when a user reported a bug that it didn't just match the name / prefix, but also if the string contained the name, which was surprising behavior); https://docs.docker.com/reference/cli/docker/network/ls/#filter

The id filter matches on all or part of a network's ID.
...
The name filter matches on all or part of a network's name.

The following filter matches all networks with a name containing the foobar string.

off-topic; perhaps we should rename this to timestamp.Parse() - I thought we did when moving, but maybe we left that for a follow-up exercise 😂