Needed: contains/issubstr/issubseq for (::String, ::String)

[kmsquire]

As suggested in #2890 and #2574, it would be nice to have a simple predicate for testing when a string contains a substring (or when a substring is part of a string).

• contains seems the most relevant, but has been shot down twice supposedly because it's inconsistent with contains(collection, elem).
• issubstr or issubstring is a possibility
• issubseq has been suggested, and could also be used for vectors
• Edit: substr in str, if in becomes an infix operator and/or we're willing to overload it like this

My personal preference is to just use contains--it's the most understandable and easy to find, even if it doesn't have exactly the same meaning as contains(collection, elem). ( Edit: substring in str is also quite nice.)

But either way, it would be nice to have a simple predicate. Having to write substring(somestring, shortstring) != 0:-1 is ugly.

What are people's preferences/suggestions?

[StefanKarpinski]

I'm ok with contains(str,sub), but I actually dislike contains for checking if a container has an element in it. I'd rather write that as in(elem,container) or better still elem in container.

[quinnj]

Related #2703.

[JeffBezanson]

This breaks down for loosely-typed containers; contains(Vector{Any}, Vector{Any}) is totally ambiguous. AFAIK python makes strings a special case for this.

[kmsquire]

@JeffBezanson, are you against making Strings a special case in Julia?

You also suggested issubseq previously. This sounds slightly awkward to me, but it's still a step up from substring(somestring, shortstring) != 0:-1

[StefanKarpinski]

That's why contains for set containment and in for elemental containment strikes me as a good way to go. Of course, this makes deprecating our current contains impossible, but it may be worth it for a clearer API.

[JeffBezanson]

So in will be what contains is now, i.e. testing whether something is one of the items generated by iterating something, and contains will default to that, except have some other behaviors like substring testing as well? What does contains mean exactly then? How do we decide what it does for contains(Vector{Any}, Vector{Any})?

[StefanKarpinski]

Arguably contains should maybe not even default to that but only be used for substructure containment: is a string a substring of another? Is a set a subset of another? Is one sequence a subsequence of another.

[toivoh]

+1 to differentiate between substructure and element containment

On Tue, Aug 27, 2013 at 4:41 PM, Stefan Karpinski
[email protected]:

Arguably contains should maybe not even default to that but only be used
for substructure containment: is a string a substring of another? Is a set
a subset of another? Is one sequence a subsequence of another.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4153#issuecomment-23341725
.

[JeffBezanson]

Sounds good to me.
The difficulty of deprecating is an issue, as is the flipped argument order --- ele in set vs. set contains subset. iscontained would be kind of awkward.

[StefanKarpinski]

For deprecation, we can, for now, have methods where e.g. contains(::Set{Int}, ::Int) is deprecated and calls in and then remove that in the future. I suspect the ambiguous contains(::Set, ::Set) case isn't all that common, but yes, we can't deprecate that effectively – it will just break.

[JeffBezanson]

That's fine; I think the flipped argument order is a more serious problem.

[StefanKarpinski]

I'm unclear on what the flipped argument order problem is. Why is it a problem that contains and in have different argument orders?

[JeffBezanson]

There are various functions that look for something in something else (search, match, findin, contains etc.) and I find it confusing that the needle and haystack are not always passed in the same order.

[StefanKarpinski]

These are collection, pattern: search, findin, contains; these are pattern, collection: match, in. More?

[JeffBezanson]

Decision: deprecate contains(x,y) to in(y,x), except add contains(String,String).

[JeffBezanson]

And let's not get started on iscontains or isin :)

[blakejohnson]

@StefanKarpinski haskey is also collection, pattern. k in keys(d) is an even nicer idiom, though.

[StefanKarpinski]

Ah good point. We should replace as many of these as we can with in idioms now that we have the infix syntax.