Should (p - q) be disallowed in @safe code?
Richard (Rikki) Andrew Cattermole
richard at cattermole.co.nz
Thu Jan 1 08:45:24 UTC 2026
On 01/01/2026 9:24 PM, user1234 wrote:
> On Thursday, 1 January 2026 at 07:27:04 UTC, Richard (Rikki) Andrew
> Cattermole wrote:
>> On 01/01/2026 8:19 PM, Walter Bright wrote:
>>> On 12/31/2025 10:54 PM, Richard (Rikki) Andrew Cattermole wrote:
>>>> Make it ptrdiff_t not size_t, and I'm happy.
>>>
>>> My bad.
>>
>> I wasn't correcting you, I was saying what I wanted it to do.
>>
>> ```d
>> void func(void* a, void* b) {
>> ptrdiff_t diff = b - a;
>> // size_t diff = b - a; ERROR
>> assert(diff >= 0, "ARGUMENTS BACKWARDS");
>> }
>> ```
>
> Yes but this has nothing to do with the substraction. You simply hit the
> implicit corecions rules there
>
> ```d
> ptrdiff_t a;
> size_t b;
> a = b;
> b = a;
> ```
>
> You need some kind of tracking/dfa/vrp to put restrictions. Same remark
> about the initial question I would say. You can imagine some code based
> on aliasing where `p - q` is finally totally fine. however `@safe` is
> good deal I would say.
That sounds completely overkill.
Disable implicit unsigned <-> signed conversion, for a subtraction of
pointers.
Doesn't need to be inter statement and definitely does not need to solve
exact values for the pointers, which may only be known at runtime with
100% certainty.
More information about the Digitalmars-d
mailing list