add std.array.pointer as @safe alternative to .ptr

[timotheecour]

• addresses https://issues.dlang.org/show_bug.cgi?id=18529
• proposed here https://forum.dlang.org/thread/mailman.301.1519721047.3374.digitalmars-d@puremagic.com?page=2
• eg use case: https://forum.dlang.org/post/lqvihadaufwivbiigtqv@forum.dlang.org or anywhere where we want .ptr for a potentially empty slice in @safe code

[dlang-bot]

Thanks for your pull request and interest in making D better, @timotheecour! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[n8sh]

Maybe add an explanatory note that a.ptr could be an invalid but non-null address if a was produced by slicing another array a = b[$ .. $], so it's clear to readers that this function is doing something that might prevent memory corruption and isn't just jumping through hoops to appease the compiler.

[timotheecour]

done

[n8sh]

"en" -> "an"

[timotheecour]

done

[schveiguy]

should this target stable

No, stable shouldn't get new features.

I'm OK with this addition. Ping @andralex for feedback on adding this one-liner. While it's trivial and easy to do with a ?: operator, a developer might appreciate a wrapper for this as a drop-in replacement for .ptr in his safe code.

[JackStouffer]

I don't think this is behavior we should encourage. In pretty much all cases, you'd want to avoid .ptr all together in @safe code. The printf example in the bug report seems contrived because printf isn't @safe anyway.

[schveiguy]

@JackStouffer the impetus for this change was from here: https://forum.dlang.org/post/lqvihadaufwivbiigtqv@forum.dlang.org

In any case, I'm also fine rejecting this, but it's at least correctly @safe.

[n8sh]

I don't think this is behavior we should encourage.

Even in non-safe code this is a better way to get the pointer for an array of unknown provenance.

[JackStouffer]

https://forum.dlang.org/post/lqvihadaufwivbiigtqv@forum.dlang.org

TBH this also seems like a contrived example. How often are C functions which take pointers marked as @safe?

[schveiguy]

It's definitely a contrived example, fun isn't a real function!

But any time you want to pass a value by reference, it's going to be a pointer in C. This could be perfectly safe. I've seen many functions that have parameters of "pass in a pointer to X if you want it filled. If you pass in NULL the value is ignored".

[schveiguy]

BTW, I agree this use is of very limited value. Even though I'm arguing that there are some use cases, and that it is indeed valid @safe code, I'm not saying it's important to get it into phobos. Certainly, people can write the arr.length ? &arr[0] : null thing directly.

[timotheecour]

arr.length ? &arr[0] : null

actually this'll lead to less efficient code compared to this PR (unless -noboundscheck is passed) so the alternative is not so nice

[schveiguy]

actually this'll lead to less efficient code compared to this PR

Yes, I know. But it doesn't have to, the compiler could easily elide the bounds check in that expression.

[WalterBright]

This pr is a strong no from me, but I'll leave it open for a while so everyone can have a say on it. As @schveiguy posted earlier, the idea is to bounds check &array[0] so the pointer points to valid data. I don't think this addition to std.array adds much of any value.

[andralex]

We don't need this kind of one-liners catering to rare cases. The code can be inlined as needed.

[schveiguy]

With a strong "no" from both the big guys, I think we can safely close this. Good news is, it's easy to do something like this in your project if you want it.

@WalterBright would it be worth opening a bugzilla request for the bounds check to be elided on arr.length > 0 ? &arr[0] : null ?