Date: Wed, 23 Sep 2020 20:58:01 -0400
On Wed, Sep 23, 2020 at 7:58 PM Eric Lengyel via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > `data` would presumably return a `disjoint float*`, which is an out-right lie, since it is very much *not disjoint*
>
> It is not the intention to provide any kind of alias safety whatsoever in this proposal, which is something I don't think can reasonably be done anyway. Also, there is nothing about disjoint that is intended to guarantee no duplicate pointers to disjoint storage exist. Disjointness is not a property of the pointer itself
>
> > So why is it part of the type system?
>
> This is discussed in the proposal. It provides type safety that goes above and beyond what you'd get with restrict, and it allows overloading so that it's possible to have different versions of a same-named function depending on whether assumptions of disjointness can be made about the inputs.
I don't think you're quite understanding what I'm getting at.
`disjoint` is a part of the type system. A `disjoint float` is a
different type from a `float`. It has an inherently different meaning
from a `float` or a `const float`. That's what it means for it to be a
cv-qualifier.
So if I have a pointer/reference to a `disjoint float`, why can I do
things with it that are inherently *antithetical* to the meaning of
`disjoint float`? I can't (easily) violate the meaning of `const
float`; if I have a pointer/reference to a `const float`, I don't get
to modify it without a cast. That would be a non-`const` operation,
and the whole point of `const` is to stop me from doing non-`const`
things to it. That's what it means.
Sticking `const` in the type system has a *substantial* cost. There
are so many places in the standard that have to be messed with in
order for `const` to exist and work. Wording for overload resolution
has to exist and be involved in ranking. You have to account for such
qualifiers in doing `same_as` comparisons in concepts. Etc.
That cost ought to buy something. `const`-correctness buys something
because it prevents you from using the object in a non-`const` way.
What does `disjoint` buy me that is anywhere near the cost? If it's
not actually going to stop me from doing non-`disjoint` operations on
the objects, then why is it part of the object's type?
You say it provides type safety. OK: where? If I have a `float
disjoint*`, in what cases does this provide safety for my use of this
type? Where is the type system preventing me from doing inherently
unsafe things like copying that pointer or storing a reference to it?
The only ones I can think of are if you call a function that has
`disjoint`-qualified versions. So within this narrow case, it provides
some type safety benefits. But beyond that, where is the type safety?
Breaking the C++ type system should require more effort than: `auto p
= disjoint_ptr;`. I fail to see that as providing type safety.
<std-proposals_at_[hidden]> wrote:
>
> > `data` would presumably return a `disjoint float*`, which is an out-right lie, since it is very much *not disjoint*
>
> It is not the intention to provide any kind of alias safety whatsoever in this proposal, which is something I don't think can reasonably be done anyway. Also, there is nothing about disjoint that is intended to guarantee no duplicate pointers to disjoint storage exist. Disjointness is not a property of the pointer itself
>
> > So why is it part of the type system?
>
> This is discussed in the proposal. It provides type safety that goes above and beyond what you'd get with restrict, and it allows overloading so that it's possible to have different versions of a same-named function depending on whether assumptions of disjointness can be made about the inputs.
I don't think you're quite understanding what I'm getting at.
`disjoint` is a part of the type system. A `disjoint float` is a
different type from a `float`. It has an inherently different meaning
from a `float` or a `const float`. That's what it means for it to be a
cv-qualifier.
So if I have a pointer/reference to a `disjoint float`, why can I do
things with it that are inherently *antithetical* to the meaning of
`disjoint float`? I can't (easily) violate the meaning of `const
float`; if I have a pointer/reference to a `const float`, I don't get
to modify it without a cast. That would be a non-`const` operation,
and the whole point of `const` is to stop me from doing non-`const`
things to it. That's what it means.
Sticking `const` in the type system has a *substantial* cost. There
are so many places in the standard that have to be messed with in
order for `const` to exist and work. Wording for overload resolution
has to exist and be involved in ranking. You have to account for such
qualifiers in doing `same_as` comparisons in concepts. Etc.
That cost ought to buy something. `const`-correctness buys something
because it prevents you from using the object in a non-`const` way.
What does `disjoint` buy me that is anywhere near the cost? If it's
not actually going to stop me from doing non-`disjoint` operations on
the objects, then why is it part of the object's type?
You say it provides type safety. OK: where? If I have a `float
disjoint*`, in what cases does this provide safety for my use of this
type? Where is the type system preventing me from doing inherently
unsafe things like copying that pointer or storing a reference to it?
The only ones I can think of are if you call a function that has
`disjoint`-qualified versions. So within this narrow case, it provides
some type safety benefits. But beyond that, where is the type safety?
Breaking the C++ type system should require more effort than: `auto p
= disjoint_ptr;`. I fail to see that as providing type safety.
Received on 2020-09-23 19:58:12