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
