Go generic collections should leave ordering with its owner

A reusable collection should ask for the ordering its operation needs without taking ownership of every ordering the application might use. A comparison method is useful when a type has a meaningful self-comparison contract. A function comparator is useful when callers need different orders over the same values. Choose between them according to who owns that decision, rather than forcing one generic API shape onto every use.

This November 2026 reading looks back at Axel Wagner's Generic interfaces, published on 7 July 2025. The tutorial develops several collection designs rather than announcing a new generics release. Go's earlier introduction to generics, dated 22 March 2022, supplies the language background. Keeping those dates distinct prevents a design tutorial from becoming an invented feature-launch milestone.

One type can participate in several business orders

Consider an illustrative application with a collection of appointments. One screen orders them by start time. Another groups them for staff review, with a different priority. The values are the same, but the useful ordering belongs to each operation. Neither screen should silently redefine how the other interprets an appointment's comparison method.

A caller-supplied comparator makes that choice explicit at the collection boundary. The function can express the order appropriate to the current task without requiring the domain type to acquire a new method. That matters particularly when the element type comes from another package or is shared by several parts of the application. The collection can remain reusable while its callers retain the local meaning of priority.

This flexibility also creates a responsibility. Callers need to understand what a comparison result means and supply an ordering that the collection can rely on. A comparator chosen casually can make equality, duplicate handling or traversal surprising. Those semantics deserve documentation regardless of whether comparison is implemented by a function or a method.

For a business application, surprising order can be a correctness problem before it is a performance problem. A review queue that presents the wrong item first may violate the intended operating procedure even if every item is eventually available. This example is hypothetical. It motivates defining ordering at the relevant boundary; it does not claim a measured failure or a particular business outcome.

Self-comparison can be a small, useful contract

The July tutorial shows how a generic interface can express a method that compares an element with another element of the same type. Parameterizing the interface avoids requiring a concrete type's comparison method to accept a library-specific interface value. That lets the constraint describe a relationship the type already has, rather than redesigning the type around the collection.

This approach is attractive when there is one appropriate order for the intended use and the element already supplies it. The collection can obtain comparison behavior through the type. A caller does not have to pass a function merely to restate an established operation. The interface earns its place by expressing a precise requirement.

The strongest argument for method-based comparison is simplicity at the point of use. An empty collection can potentially be ready without a separate comparison function being installed. A method can also give the compiler different optimization opportunities. The tutorial discusses those tradeoffs, but it does not establish which representation is fastest for your application. Select the semantics first; justify performance claims with relevant evidence if performance later drives the decision.

That argument has limits. A comparison method does not automatically become the right order for every customer task. Nor does a type's ability to compare itself mean the collection should demand more methods than its operations use. Keep the required contract narrow enough that a caller can recognize why it exists.

Zero-value usefulness is a design promise

In the tutorial's function-field design, the comparison function needs explicit initialization, so the empty zero value is not immediately usable in the same way as the method-based alternative. This is a property of that design, not proof that every function-based API must have a useless zero value. A function could instead be supplied at an operation boundary, or a different public interface could make initialization explicit.

Decide what users can expect before choosing the representation. If an empty collection is intended to be ready on declaration, preserve that promise in both documentation and behavior. If construction requires a comparator, make the construction step visible and explain what it establishes. A hidden initialization requirement is harder to discover than an explicit one.

A library need not expose every available design just because all can share internal machinery. Multiple entry points can be justified when they serve distinct callers, but each adds a contract to explain and maintain. Start with the operations the library needs to support. Offer additional shapes when there is a concrete use that the existing surface handles poorly.

There is a related distinction between order and other collection requirements. An ordered structure and a structure that also uses map keys may impose different constraints on elements. Adding a requirement for an internal convenience can exclude callers who do not need that convenience. Inspect which operation actually requires each constraint before attaching it to a general interface.

For custom software development, review the domain type and the caller together. Identify who can change the type, which operations need different orderings and whether a ready-to-use zero value matters at those call sites. Use self-comparison when it faithfully describes the element's role. Keep a function comparator available where ordering belongs to the caller. The collection's abstraction is strongest when that ownership remains legible.