On Tuesday, 24 January 2017 at 11:49:59 UTC, Atila Neves wrote:
> But it's still annoying to have to do &array[0] just to pass it to a C function, since `my_c_func(array.ptr)` isn't going to screw up anything.

How do you know it does not screw up anything? Presumably, the function somehow accesses the object the pointer targets. How would this be @safe to call if the pointer were not dereferencable?

 — David

On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis wrote:
> It seems _slightly_ better from a safety perspective but only slightly.

Wrong – one is correct, the other is not. This is because every pointer in SafeD is dereferencable. Pointer arithmetic is not allowed in SafeD, so your concerns about reading from other memory do not apply.

 — David

On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger wrote:
> This is because every pointer in SafeD is dereferencable.

But null pointers are allowed in SafeD and arr.ptr is either arr[0] or null....

On Wednesday, January 25, 2017 22:46:10 David Nadlinger via Digitalmars-d- learn wrote:
> On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
>
> wrote:
> > It seems _slightly_ better from a safety perspective but only slightly.
>
> Wrong – one is correct, the other is not. This is because every pointer in SafeD is dereferencable. Pointer arithmetic is not allowed in SafeD, so your concerns about reading from other memory do not apply.

Yes, but my point is that you're normally only going to use .ptr to pass something to a C function, and even if you're doing more with it in D, odds are, you're going to be doing pointer arithmetic. All &arr[0] does over arr.ptr is check the first element. It makes it @safe, but then everything else you're going to be doing after that almost certainly won't be @safe. And when you combine it with marking C function @trusted, this is actually pretty bad. It makes it trivial to do something like

extern(C) int cFunc(int* ptr, size_t length) @trusted;

auto result = cFunc(&arr[0], 12);

and have it be considered @safe, when it's not @safe at all. Now, most code would then do

auto result = cFunc(&arr[0], arr.length);

so in practice, it won't usally be a problem, but it makes it easy to have code treated like it's completely @safe when in fact it isn't. Now, really, the fix there is to not mark the C function as @trusted and require that the caller make sure they pass in arguments that are @safe, but at least if they were doing

auto result = cFunc(arr.ptr, arr.length);

the compiler would have caught that it was @system even with the C function being marked as @trusted, whereas if you do &arr[0], it wouldn't.

So, yes, if all you're planning to do is look at the pointer to the first element in the array, then &arr[0] is safer, but odds are quite low that that's actually what you're going to do, and in all of the other cases, you might as well just use .ptr. So, telling folks to go use &arr[0] instead of .ptr doesn't seem very helpful to me.

- Jonathan M Davis

On Wednesday, 25 January 2017 at 18:12:18 UTC, Jonathan M Davis wrote:
> Fine, but in the vast majority of cases, you're calling .ptr, because you're going to be passing the pointer to C code, in which case, doing &arr[0] buys you very little, since the C code is inevitably going to be reading more than that one element,

In that case, calling the C function isn't going to be @safe anyway, so you might as well use .ptr.

> So, telling the programmer to use &arr[0] instead of arr.ptr is just plain bizarre.

What you call bizarre is a simple, actionable explanation (which is especially important as the behaviour was necessarily a backwards-incompatible change). If &arr[0] doesn't actually apply to your code, then it was mistakenly @safe before.

 — David

On Wednesday, 25 January 2017 at 22:54:32 UTC, Adam D. Ruppe wrote:
> On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger wrote:
>> This is because every pointer in SafeD is dereferencable.
>
> But null pointers are allowed in SafeD and arr.ptr is either arr[0] or null....

This is a fallacy:

---
@safe: // Deprecated, though.

ubyte oops(ubyte[] b) {
    return *b.ptr;
}

void main() {
    oops(new ubyte[0]);
    // - or -
    auto b = new ubyte[42];
    oops(b[$ .. $]);
}
---

 — David

On Wednesday, 25 January 2017 at 23:09:11 UTC, David Nadlinger wrote:
> This is a fallacy:

Ah, yes indeed, that was mentioned earlier in the thread too, it just slipped my mind again.

On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis wrote:
> Yes, but my point is that you're normally only going to use .ptr to pass something to a C function, and even if you're doing more with it in D, odds are, you're going to be doing pointer arithmetic.

Wrong again. If this were the case, we wouldn't have needed to make it a deprecation at all, since all uses would have been mistakes. A non-negligible amount of real-world D code actually uses single-object pointers. Look up the change history if you are interested – and indeed, making sure one understands the topic sufficiently well to meaningfully contribute before typing out a wall-length sermon would collectively save us a good chunk of time.

> And when you combine it with marking C function @trusted, this is actually pretty bad.

Ex falso quodlibet – once you have a piece of code mistakenly marked @trusted, all guarantees are out of the window even without suspicious-looking client code. @safe-ty is about mechanically verifiable code, not faith-based programming.

 — David

On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis wrote:
> So, while it makes sense to say that .ptr can't be used in @safe code, it really doesn't make sense to suggest &arr[0] as an alternative.
>
> - Jonathan M Davis

Sure I see your point. But I feel like deprecations should also list what one can do instead. So in that regard the suggestion makes sense.

On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis wrote:
> So, yes, if all you're planning to do is look at the pointer to the first element in the array, then &arr[0] is safer, but odds are quite low that that's actually what you're going to do, and in all of the other cases, you might as well just use .ptr. So, telling folks to go use &arr[0] instead of .ptr doesn't seem very helpful to me.


Pehaps it should say something like: arr.ptr is deprecated in @safe code. Use &arr[0] for checked access or remove the @safe attribute.

That would make it clear that .ptr is not an issue, only .ptr in @safe.