Date: Tue, 22 Sep 2020 13:06:03 -0700
> 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. As highlighted in the proposal, applying restrict to a pointer leads to inconsistent language constructs, and it is not amenable to overloading. Applying the disjoint qualifier to the actual storage makes it possible to cleanly implement the mechanism intended by restrict in C++.
> 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;
> 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.
From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Sent: Tuesday, September 22, 2020 10:26 AM
To: Std-Proposals <std-proposals_at_[hidden]>
Cc: Eric Lengyel <lengyel_at_[hidden]>
Subject: Re: [std-proposals] RFC: disjoint qualifier
On Thu, Sep 17, 2020 at 9:38 PM Eric Lengyel via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
http://terathon.com/disjoint_lengyel.pdf
I still don't understand how your new type-qualifier is supposed to help at all.
Normally I like proposals that show exact wording — it clarifies one's thinking — but in this case I think you have done all the wording before you've come up with any use-cases, and I think that's a problem. I'd like to see some use-cases and sample code.
Your very first snippet says:
int *a;
const int *p = a; // OK: const qualifier added
disjoint int *q = a; // error: disjoint qualifier cannot be added
So, if I were trying to use `disjoint` in the same way as `restrict`, and wrote this snippet:
void foo(disjoint int *r, disjoint int *s);
int a, b;
foo(&a, &b);
you're telling me that that wouldn't compile? Because `&a` is obviously an expression of type `(int*)` — you can't change that — and you've just told me that `int*` is not implicitly convertible to `disjoint int*`.
So what is the intended usage of `disjoint`? What does it say about the pointee, and how could the compiler use it to produce better codegen?
Also consider what you'd do with
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. Isn't that a problem? What in your proposal deals with this kind of thing?
–Arthur
The use cases are exactly the same as they are for restrict in C, which I assume you’re familiar with. As highlighted in the proposal, applying restrict to a pointer leads to inconsistent language constructs, and it is not amenable to overloading. Applying the disjoint qualifier to the actual storage makes it possible to cleanly implement the mechanism intended by restrict in C++.
> 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;
> 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.
From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Sent: Tuesday, September 22, 2020 10:26 AM
To: Std-Proposals <std-proposals_at_[hidden]>
Cc: Eric Lengyel <lengyel_at_[hidden]>
Subject: Re: [std-proposals] RFC: disjoint qualifier
On Thu, Sep 17, 2020 at 9:38 PM Eric Lengyel via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
http://terathon.com/disjoint_lengyel.pdf
I still don't understand how your new type-qualifier is supposed to help at all.
Normally I like proposals that show exact wording — it clarifies one's thinking — but in this case I think you have done all the wording before you've come up with any use-cases, and I think that's a problem. I'd like to see some use-cases and sample code.
Your very first snippet says:
int *a;
const int *p = a; // OK: const qualifier added
disjoint int *q = a; // error: disjoint qualifier cannot be added
So, if I were trying to use `disjoint` in the same way as `restrict`, and wrote this snippet:
void foo(disjoint int *r, disjoint int *s);
int a, b;
foo(&a, &b);
you're telling me that that wouldn't compile? Because `&a` is obviously an expression of type `(int*)` — you can't change that — and you've just told me that `int*` is not implicitly convertible to `disjoint int*`.
So what is the intended usage of `disjoint`? What does it say about the pointee, and how could the compiler use it to produce better codegen?
Also consider what you'd do with
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. Isn't that a problem? What in your proposal deals with this kind of thing?
–Arthur
Received on 2020-09-22 15:06:09