Should (p - q) be disallowed in @safe code?

[Walter Bright]

On 1/1/2026 6:11 PM, Timon Gehr wrote:
> On 1/1/26 23:14, Walter Bright wrote:
> I understand, but your latest point was "just put `@trusted` on it".
> 
> Let's say the frontend now treats `p-q` as `@system`, and there is not even any 
> documentation of what its semantics is supposed to be.

It's semantics are subtract q from p and divide by the size of the pointed to type.


> Do you believe with this background, alternative backends will in the future be 
> more likely to:
> 
> - treat `p-q` as UB when different memory objects are involved
> 
> - treat `p-q` as defined behavior when different memory objects are involved

Let's step back a bit. I expect it to behave as a C backend would. More 
precisely, I have read the C/C++ memory model specification. It is very 
carefully written and well done. I requested a license to copy it to use in the 
D specification, but my request was ignored.

I could rewrite it to an equivalent definition, but that's a lot of work.

But still, D is going to adhere to it. It works, everyone understands it, and 
the existing backends are carefully tuned to match it.

All my proposal does is disallow pointer subtraction in @safe code. Code 
generation is not affected in any material way.

It's the same thing as disallowing p+=1 in @safe code. The memory model does not 
change.


> I just think the overall effect of this will be to cause confusion about what is 
> allowed among all parties involved. I think it's better to stick to banning 
> language constructs from `@safe` if they can actually exhibit UB.

Isn't that what I proposed?


> And yet it seems for `p-q` you differed.

How did I differ? I am confused.