Sure, but the language should offer support for this, even if it requires some level of configuration. It's not a problem we want every programmer solving anew for every program.

> I wouldn't rely on something like string.equals for it.

True enough. But I think the existing String.equals method is broken: it behaves very surprisingly and leads programmers to introduce bugs. Likewise e.g. String.subString (which can chop a character in half). These methods cannot be fixed (because existing code assumes their current functionality) and are very difficult to use effectively; they should be deprecated, which in practice means a new String type.

Yeah, I completely agree. You can make an argument that this stuff belongs in a library (or even several libraries) rather than the language, simply because of how many decisions are involved:

- do you know what language your search input is in? can it be any of several languages? any at all? only one specific language, ever?

- what language is the text you're searching on? do you know? are you potentially searching across text in multiple languages at once?

- how exact does the match need to be? do you want phonetic matches? do you want to match characters that "look" similar but many sound different?

- do you need a binary or a fuzzy match? (e.g. are you doing a search ranked by relevance). Do you need to compute some sort of Levenshtein distance?

So the use cases can range from a simple byte-level exact comparison all the way to a full search server like Solr. How much of that should the language implement? (not a rhetorical question, I actually don't think there's an obvious answer).

No arguments on the existing String methods :)