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