Nevin Liber <nevin_at_[hidden]> writes:

[...]

| 3. Pointers, while historically not totally ordered, are practically so for
| all systems in existence today, with the exception of the ivory tower minds of
| the committee, so the point is moot.

You keep repeating the "history" bits. That is fine. History is
important, not just because it talks about specific event at specific
points in the past, but also because it gives us perspective over
what followed and what is to come.

I personally do not care about the relevance of segmented architectures
at this specific point in time. However, I am very much open to be
persuaded of their relevance in the future, non-uniform address spaces,
etc, but then I would likely press and ask whether you should consider
different kinds of pointers etc.

The semantics of comparison of pointers with the "operator<" syntax
isn't -just- comparison of addresses; it carries aliasing implications
as specifies in its semantics. That is not true of std::less<T*>.
For example, what about "p - q" when p and q are pointers? In my view,
a meaningful discussion about changing "operator<" should be initiated
by a paper that conducts a calm and thorough analysis of how operator<
relates all other operations and comparisons on pointers, and what the
impacts are and proposed a coherent set of changes. An example of this
was recently done for the preprocessor part. I fear repeating the
historical existence of segmented architecture and their extinction
isn't a substitute.
 
Talking about perspective. I can't help but remember the lively
discussion and atmosphere in Chicago when I threw "signed integer
arithmetic overflow" as strawman. There was quite a sizeable majority of
the audience who believed or made the argument that not just because at
the hardware level, the signed arithmetic will wrap means that it is
necessarily the right semantics at the language level. Leaving the
semantics undefined or unspecified gives the opportunity to build tools
to catch errors in programming logic, and people have done that.

Similarly, not just because at the architecture level, for the vast
majority of them, the address space is totally ordered means that is
what should be reflected at the language level. It makes sense to
desire leaving room for tools to catch programming errors where the
"wrong" pointers are being compared -- we certainly have experience with
more general iterators, and people love the debug version of STL; I
don't think it is a stretch to conceive that is always useful for the
unbridled pointers.

-- Gaby