On Tue, Sep 22, 2020 at 4:06 PM Eric Lengyel via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > I think you have done all the wording before you've come up with any
> use-cases, and I think that's a problem
>
>
>
> The use cases are exactly the same as they are for restrict in C, which I
> assume you’re familiar with.
>

Don't assume. It can't help, but (if you assume wrong) it might hurt.


> > void foo(disjoint int *r, disjoint int *s);
>
> > int a, b;
>
> > foo(&a, &b);
>
> > you're telling me that that wouldn't compile?
>
>
>
> Correct, that would not compile. You would need to declare a and b like
> this instead:
>
> disjoint int a, b;
>

That doesn't sound useful or semantically correct. I mean, aren't any two
local variables always semantically disjoint? How should the programmer
decide which variables to declare using the `disjoint` keyword and which
ones to leave alone?

> disjoint int *p1 = ...;
>
> > auto p2 = p1;
>
> > static_assert(std::same_as<decltype(p1), decltype(p2)>); // ???
>
> > If p2's type is the same as p1's, then they're both `disjoint int *` —
> and so you have two `disjoint int *` objects that point to the same place.
>
>
>
> Yes, p1 and p2 both have type ‘disjoint int *’, and they both point to the
> same object. It is the programmer’s responsibility to use such pointers
> correctly, exactly the same as it would be with restrict, but with the
> added type safety that disjoint allows.
>

It's the *programmer's responsibility* to track which `disjoint` variables
are actually disjoint?
So the keyword provides *no* helpful semantics?
That's not my definition of "type safety." To me, "type safety" means that
the compiler should
(A) prevent having two `disjoint` pointers to the same storage, or at least
make it easier to write static-analyzer passes to detect that issue
(B) permit seamlessly converting non-`disjoint` pointers to `disjoint`
pointers, in the case that they are in fact disjoint

Your proposal does neither of these things, so, basically, it seems like it
doesn't do *anything*.

Use-cases, with sample code, would help.

–Arthur