Add isSliceOf to check the origin of a slice

[wilzbach]

This is has come up before:

• Add std.array.isSliceOf #2416
• https://forum.dlang.org/post/[email protected]

tl;dr: of the previous discussion:

• overlap exists, 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)
  • sameHead and sameTail already exists
  • @trusted doesn't work for one-liners

CC @nordlow @dcarp

[dlang-bot]

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"

[JackStouffer]

std.exception.doesPointTo?

[wilzbach]

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

[wilzbach]

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

[nordlow]

Thanks, @wilzbach for making ideas become real work.

[JackStouffer]

Any reason to not use the &whole[0] style rather than whole.ptr?

[wilzbach]

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));

[JackStouffer]

null isn't a slice of itself because null isn't anything. Nothing can't be a part of nothing.

[wilzbach]

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.

[JackStouffer]

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.

[MetaLang]

I don't think it's too bad to say that null.isSliceOf(null) is true.

[JackStouffer]

a safe way to query what?

[JackStouffer]

The null thing isn't a blocking issue for me. I approve baring that changelog nitpick.

[n8sh]

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!

[thewilsonator]

Ping @andralex

[andralex]

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!

[andralex]

To clarify I am asking for changes.

[thewilsonator]

IMO your suggestion fall foul of

overlap exists, 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.

[andralex]

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

[andralex]

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.

[thewilsonator]

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.

[andralex]

@thewilsonator wouldn't disagree. I still think this should be relegated to a documentation example. Thanks.

[RazvanN7]

@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.

[LightBender]

@thewilsonator you wanted this one.

[LightBender]

@thewilsonator you wanted this one.