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

> > Don't assume. It can't help, but (if you assume wrong) it might hurt.
>
>
>
> I was simply attempting to acknowledge the likelihood that you possess
> some familiarity with the subject material because many people seem to get
> offended if I explain it to them as if they didn’t already understand.
>

Providing some use-cases and example code is a good idea.
You should provide some use-cases and example code.

[...]

> > 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
>
>
>
> That is “alias safety”, not “type safety”. Type safety means that you
> can’t accidently pass a pointer to a non-disjoint object to a function
> expecting a disjoint object. The restrict qualifier provides no such safety
> (and cannot be made to), but the disjoint qualifier does. Static analyzers
> are certainly able to detect cases in which a program creates two pointers
> to the same disjoint storage (which by itself is not dangerous) and uses
> them in a suspicious manner (perhaps by passing both as different
> parameters to the same function).
>

Sure, and static analyzers are equally well able to detect cases in which a
program creates two pointers to the same *non-disjoint* storage and passes
both as different parameters to the same function.

void foo(restrict int *p, restrict int *q);
void test(restrict int *c, restrict int *d) {
    int a, b;
    foo(a, a); // static analyzer should warn
    foo(a, b); // static analyzer should not warn
    foo(c, c); // should warn
    foo(c, d); // should not warn
}

Your `disjoint` doesn't seem any different from `restrict`, in that sense.


 (B) permit seamlessly converting non-`disjoint` pointers to `disjoint`
> pointers, in the case that they are in fact disjoint
>
>
>
> No, no, no! You’re completely missing the point of the type safety here
> and the need for the reversed implicit-subtract semantics. The ability to
> seamlessly convert non-disjoint to disjoint is exactly why the noalias
> qualifier was rejected so harshly way back in the 80s:
>

If there's a problem with it, show the problem via an example and put the
example in your paper.
However, it's even more important to show how your proposal *fixes* the
example. If it's just "My proposal prevents you from writing the bad code,"
that isn't good enough, because the status quo also prevents you from
writing the bad code. You need a proposal that *enables* writing *better*
code.

HTH,
Arthur