can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[ag0aep6g]

On 02/27/2018 06:32 PM, Atila Neves wrote:
> On Tuesday, 27 February 2018 at 12:39:04 UTC, Jonathan M Davis wrote:
[...]
>> In almost all cases, &a[0] is equivalent to a.ptr except that it does 
>> bounds checking, so it's actually @safe and thus doesn't need to be 
>> manually verified by the programmer, unlike your pointer function 
>> suggestion.
> 
> There's a common case where it's not equivalent - when the pointer is 
> null. Imagine I have a C function I want to call:
> 
> extern(C) void fun(int* things);
> 
> Imagine also that it's ok to call with null. Well, now I can't use a 
> slice to call this and have it be 1) @safe and 2) not throw RangeError. 
> I ran into this the other way.

As Jonathan says, you have to manually verify that it's safe, because it 
generally isn't. `arr.ptr` can be invalid but not null, even in @safe code.

Consider:

----
void fun(int* things) @safe
{
     int x = things is null ? 0 : *things;
     import std.stdio;
     writeln(x);
}

void main()
{
     int[] arr;
     fun(arr.ptr); /* Ok, prints "0". */

     arr = [1, 2, 3];
     fun(arr.ptr); /* Ok, prints "1".*/

     arr = arr[$ .. $]; /* This is @safe. */
     fun(arr.ptr); /* Not ok, prints garbage. */
}
----

The first two calls are actually safe and can be @trusted. The third 
call is invalid and must not be possible in @safe code.

Maybe it would be possible require `arr.ptr` to be valid or null in 
@safe code. This would outlaw `arr[$ .. $]` and bounds checking would 
have to catch it. I don't know if that would be any practical than 
banning `arr.ptr`.