On Wed, 23 Sep 2020 at 05:21, Rand McRanderson via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Is it just me or does restrict seem like something that should be an attribute more than a keyword? I have always felt like it was more of a compiler or analyzer hint than a guarantee of certain behavior (of course the same could be said of several keywords). C compatibility would be easy with
>
> #ifdef __cplusplus
> #define restrict [[restrict]]
>
> Just a thought

I don't think it's just you. I find making disjoint a cvd-qualifier
alarming, especially now that we are moving towards
making cv-qualifiers c-qualifiers, and decreasing the impact of
volatile on the language. There's probably as much if not
more abuse of volatile member functions as/than there are reasonable uses.

So, I have a bunch of questions/ruminations/remarks about this:

1) What are the use cases for having a disjoint this pointer?

2) If I have a Foo::operator=(disjoint Foo&&) disjoint;, that's
presumably a move assignment operator,
so it's considered a special member function. Curiously enough, that
seems to be a flavor of a move assignment
operator that knows that self-move is not possible. Even more
curiously, that doesn't mean that the disjointness
necessarily leads into a compiler optimizing away self-move checks,
because since this is a separate function,
it could just be written not to do such checks.

3) The proposal does include disjoint references as well as pointers,
right? Right? Right?

4) It seems very heavy-handed to turn an optimization into something
that's deep in the semantics of the language.
It becomes viral. For template code and inline code, an optimizer can
just see that I have distinct objects and optimize
accordingly; for function definitions in a separate TU, I need such an
attribute/keyword to be able to tell the compiler
that it can assume distinct objects. That should be rare, and I
question whether that should be the burden of all
layers in a program to worry about.

5) Adding a new cvd-qualifier makes this a big-impact change to the
language, an in-your-face one. Granted, it's not
in everybody's face; after all, volatile isn't, most C++ programmers
just ignore the whole existence of it. Some misunderstand
it and misuse it, so that's a teaching cost. Making it so prominent as
to make it a cvd-qualifier increases that cost.

6) Consider
    disjoint Foo a;
    disjoint Foo* b = &a; // #1
    disjoint Foo* c = nullptr;
    c = b; // #2
Is this well-formed? How is a pointer disjoint if it can be assigned
from another disjoint pointer? I'd think that's by definition not
disjoint.
In a similar vein,
    disjoint Foo a;
    disjoint Foo& b = a;
    disjoint Foo& c = b; // questionable
    disjoint Foo& d = a; // indirectly questionable in the presence of b
but then again,
    Foo some_func();

    disjoint Foo&& d = some_func();

In other words: are there differences in how a disjoint
pointer/reference can be initialized (or assigned, in the case of a
pointer) between
lvalues and rvalues, and between lvalues and glvalues?

7) All this stuff seems very complex compared to being able to mark
function parameters as disjoint from each other.