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

[Atila Neves]

On Tuesday, 27 February 2018 at 12:39:04 UTC, Jonathan M Davis 
wrote:
> On Tuesday, February 27, 2018 04:20:38 Timothee Cour via 
> Digitalmars-d wrote:
>> [...]
>
> Except that that's really not how @trusted is supposed to be 
> used. The programmer needs to verify that the caller is using 
> a.ptr in a manner that is actually @safe, because the compiler 
> is not smart enough to determine that for you. Wrapping it in 
> an @trusted function means that the caller won't get an error 
> and that the programmer won't necessarily know that they need 
> to verify the calling code. It's the code that's using ptr that 
> needs to be verified, not the actual accessing of ptr.
>
> Hiding the access to ptr within an @trusted function goes 
> against that entire idea of @trusted and makes it easy to use 
> ptr without realizing that you need to be checking the code 
> that's using it, since you just called a wrapper function to 
> silence the compiler instead of listening the compiler and 
> studying the code using ptr to verify its @safety.
>
>> [...]
>
> 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.

Atila