phobos
phobos copied to clipboard
dlang
Add isSliceOf to check the origin of a slice
This is has come up before:
- https://github.com/dlang/phobos/pull/2416
- https://forum.dlang.org/post/[email protected]
tl;dr: of the previous discussion:
-
overlapexists, but is confusing to use - there were no "real world" use cases / huge interest
- @dcarp provided some and I have run into similar uses when working with allocators (it's analog to
owns) -
sameHeadandsameTailalready exists -
@trusteddoesn't work for one-liners
- @dcarp provided some and I have run into similar uses when working with allocators (it's analog to
CC @nordlow @dcarp
Thanks for your pull request, @wilzbach!
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.
Testing this PR locally
If you don't have a local development environment setup, you can use Digger to test this PR:
dub run digger -- build "master + phobos#6147"
std.exception.doesPointTo?
Sorry for not mentioning that one. It's pretty useless (and in the wrong module):
If target is a pointer, a dynamic array or a class, then these functions will only check if source points to target, not what target references.
Convince yourself: https://run.dlang.io/is/NoZVWq
Argh, the spuriously failing std.regex due to its high memory consumption is getting more and more annoying.
See also: https://issues.dlang.org/show_bug.cgi?id=18411
Any reason to not use the &whole[0] style rather than whole.ptr?
Yes - isSliceOf should work for empty arrays too, e.g.
assert(null.isSliceOf(null));
null isn't a slice of itself because null isn't anything. Nothing can't be a part of nothing.
Nothing can't be a part of nothing.
So you would treat null like FP's NaN where the default value is poison and yields false? Interesting thought!
The problem here is that null is null, so I thought it makes sense that isSliceOf matches this behavior.
If I had to be pedantic, I would say the nothing is the same as nothing but nothing is not a memory view of nothing.
Tangential to this pull request:
overlap exists, but is confusing to use
Maybe the documentation needs improvement then, because if (a.overlap(b)) should be crystal clear!
This API could be better. As it is, it returns very little information i.e. "is this range overlapping this other range in any position?" with no further information on position.
The same information can be trivially fetched using overlap in one of two ways:
small.overlap(large) is small
or
small.overlap(large).length == small.length
I like the first one more for generality, and the second more for efficiency. Given the rarity of such a query, I think we don't need a new function for it.
BUT! All is not lost. I propose to convert this PR into a documentation PR. The definition and use of isSliceOf can be put in a documentation unittest. That way we match google queries like "dlang isSliceOf" and similar. Win-win-win!
IMO your suggestion fall foul of
overlapexists, but is confusing to use
If I saw small.overlap(large) is small it would take me a good while to figure out what that meant.
As it is, it returns very little information i.e. "is this range overlapping this other range in any position?" with no further information on position.
c.f. canFind(/find), so what? The index is trivially whole.ptr - part.ptr but you'd just use part.ptr.
Given the rarity of such a query, I think we don't need a new function for it.
@dcarp provided some and I have run into similar uses when working with allocators (it's analog to owns)
The existence of one-liners on phobos exist precisely to a) stop people reinventing the wheel, and b) use a common name: this fit both of those.
Please reconsider.
The existence of one-liners on phobos exist precisely to a) stop people reinventing the wheel, and b) use a common name: this fit both of those.
(c) must be in frequent use, this doesn't pass that test
If I saw small.overlap(large) is small it would take me a good while to figure out what that meant.
"The overlap of small and large is the same as small itself, i.e. large subsumes small." For somebody in a place in life where they need overlap, this is not quite the leap.
For somebody in a place in life where they need overlap, this is not quite the leap.
I agree, but for those not in need of or familiar with overlap, small.overlap(large) is small is obtuse.
@thewilsonator wouldn't disagree. I still think this should be relegated to a documentation example. Thanks.
@andralex I have put isSliceOf into a documented unittest and have used overlap instead of pointer arithmetics. However, I had to delete a few tests regardind the behavior in the presence of null. However, I think this is fine since the point is to provide a use case for overlap.
