----- Mensaje original ----- [...]

...

composite_key</* as before*> ck; ck(record(1,2,3))<=make_tuple(1,2); // yields true make_tuple(1,2)<=ck(record(1,2,3)); // yields true

So far, this is all IMHO perfectly consistent, but the following design decision is not obvious to me: given the previous, what should be the result of

ck(record(1,2,3))==make_tuple(1,2); // true or false?

As these two objects are neither greater than the other, at least they are *equivalent*, but maybe allowing operator== to return true is too much.

It sounds to me like you have a partial ordering or a strict weak ordering, but not a total ordering. http://www.sgi.com/tech/stl/StrictWeakOrdering.html That is, these two objects: ck(record(1,2,3)) make_tuple(1,2) are in the same equivalence class, but they are not equal. My hunch is that if you call these two object "k" and "t" (key and tuple), then you should have k < t false t < k false t == k does not compile That's just my quick hunch based on what I've quoted above; I haven't considered what consequences it has for the library, but that's my intuitive notion of how tuples as "partial keys" ought to work.

I guess I agree with you, but I wanted to bring this in to the list to gather some opinions. Following your approach, what should we do with k <= t t <= k The options are: a. they hold true b. they do not compile I don't have any strong argument in favor of any option. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo