Fix Issue 17679 - SortedRange.contains should be deprecated in favor of the generic canFind

[wilzbach]

See also: http://forum.dlang.org/post/sjwsaofnanozytrvwxpb@forum.dlang.org

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Auto-close	Bugzilla	Description
✓	17679	SortedRange.contains should be deprecated in favor of the generic canFind

[wilzbach]

I duplicated the relevant unittest, s.t. we continue to test contains

[wilzbach]

@jmdavis - I hope I have done it correctly this time?
IIRC the stages were:

• mark in documentation as deprecated
• remove from documentation
• remove entirely

[bubnenkoff]

Should canFind be aliased/renamed to contains? It's more general naming.

[andralex]

The apparent duplication is intentional and useful. canFind means "can run linear find and find this value", whereas contains means "quickly rummage for this value" and must finish in logarithmic time.

[JackStouffer]

@andralex But canFind specializes for SortedRange, so there's no speed benefit to using one over the other.

[andralex]

That's an opportunistic optimization. Calling canFind means "I don't care whether this is linear, just find the thing". It's nice to have that use contains if available.

[wilzbach]

@andralex But canFind specializes for SortedRange, so there's no speed benefit to using one over the other.

Yep copy/pasting from Bugzilla:

Since #4907 (December 2016), find takes advantage of Sortedness:

phobos/std/algorithm/searching.d

Line 1509 in 57b8d25

// If the haystack is a SortedRange we can use binary search to find the needle.

[andralex]

@wilzbach the usefulness of the distinction is in generic code that wants to make sure fast searching is available

[wilzbach]

the usefulness of the distinction is in generic code that wants to make sure fast searching is available

Isn't it the opposite for generic code? It should only care about the canFind operation.
Btw I just looked at the Phobos code and the only time a function cares about whether sth. is of type SortedRange is find.
Of course, there was #3534 which proposed to do more specializations like: with isSortedRange!(Range, pred), but we don't even have isSortedRange and afaict the purpose of the SortedRange was to do the optimizations in the function (e.g. canFind) a la:

static if(isSortedRange!(Range, pred)
 // faster path
else
 // normal path

and not at the call site:

static if (hasMember!(Range, "contains"))
    r.contains(42);
else
    r.canFind(42);

Anyway I don't care about this too strongly. I just found on the NG that people struggle with it and find it confusing.

[andralex]

Offering functions of distinct complexity is within the doctrine of generic programming; there's long established practice of such in the STL, viz. member vs. non-member find. The same applies to DbI at least for as long as there's no systematic way of getting the complexity of an algorithm by means of introspection. My BigO library may challenge that notion in the future, but as things stand reflecting complexity in the name of functions is robust established practice.

The Achilles's heel of checking for SortedRange is that not only sorted ranges have fast contains - a variety of hashed containers come to mind. Any range with fast searching should implement contains. That information is vital and could make the difference between working and practically impossible as anyone who's joined two tables would know.

[JackStouffer]

@wilzbach Since Andrei has a good argument in favor and there's been no activity on this, I'm closing this. Please reopen if you have a counter point.