Hi Matthew, > Le 4 nov. 2019 à 17:03, Matthew Fernandez <matthew.fernan...@gmail.com> a > écrit : > > >> On Nov 3, 2019, at 22:52, Akim Demaille <a...@lrde.epita.fr> wrote: >> >> Hi Matthew, >> >> The semantics for line and columns are quite clear, so comparing Positions >> in the same file is quite well defined. >> >> But what should you do when the files are different? (And Locations are >> intervals, so there's no way to compare them totally in a natural order.) >> >> What we can do, though, is offer implementations for std::less, that would >> blindly apply the lexicographic order in both cases. >> >> But the case of file names remains troublesome: should we compare the >> pointer addresses (super fast, but non deterministic) or the pointees (super >> slow, but deterministic)? > > The implementation I had in mind had all operators returning false when the > filenames differed.
So this is not transitive nor anti-symmetrical, that's not an order at all. Besides, with this definition, a <= b is not equivalent to b >= a, that's frightening. > However maybe this is insufficient for defining a partial order? Some > internet reading suggests these operators cannot be used to define a partial > order and things like std::sort will malfunction. It will certainly not work properly. > I was not suggesting implementing any new operators for Locations, which I > agree are orderable this way. > > The std::less implementation you suggest is to also lexicographically compare > the filenames themselves? I’m not sure this makes sense, because source > positions from two different files aren’t really orderable at all. The point of defining std::less is to have an easy means to insert positions in a sorted container, say std::map. Now, the order in itself is well defined, but my not reflect the order the user would like to see. To be clear: I don't have a problem with std::less which I see as an implementation detail, but operators such as <= and the like are different: they express a total order that we can't implement easily. In addition, think of C where you also have main.c that #include "foo.h" somewhere, which results in main.c:1 (i.e., line 1) < foo.h:1 < ... < foo.h:42 < ... < main.c:3. If we want a total order here, it's actually easy: positions should have a counter somewhere which is the *total* "offset" since the first byte of the first file. Or something like that. But we don't have it.
