On Tue, Sep 22, 2020 at 5:41 PM Eric Lengyel via Std-Proposals <std-proposals@lists.isocpp.org> 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