As part of the revision of the graph library, I suggest that this named parameter be relabeled to distance_identity(). That would capture its general meaning, regardless of the nature of the combine method.
Brook, I mostly agree, but I think we can do better too. One of the reasons that it probably took the name distance_zero() is that there haven't been many motivating examples of non-additive combinations of distance (and hence identities). I'm wondering if it might not be worthwhile to build simple structures that provide the function types and constants for these algorithms rather than specifying them as distinct parameters. For the common case, these would simply default to the basic additive operations and identities but could be easily overridden. I'm sure there are some nice mathematical terms and properties that could describe these (monoids, semigroups, group, etc.). I'm not a mathematician, so I don't know for sure. Andrew Sutton asutton@cs.kent.edu