The reasoning in those comments seems a bit strained to me - you're looking for code examples and conventions as demonstrated by libraries, not for the libraries themselves to solve the problem in themselves.
On the other hand, "the problem" doesn't really exist in your case. The question you're trying to ask is really too subjective for Software Engineering, or for any other site on the network. It's fundamentally looking to discuss the common practice - since simply having evidence for "yes, I'm not the only person who ever thought of doing things this way" is clearly not useful to anyone. And Stack Exchange sites are not discussion forums.
The question also seems to be based on some misconceptions. The
is in function and method names is clearly intended as a signal that it's a query, not a command. It does naturally make more sense to say e.g. "is value empty" rather than "value is empty", because it is fundamentally a question, not an assertion.
But there are many other ways to signal that, which will depend on the programming language and the culture around it. For example, you already found C++'s
std::string::empty, which is like that because there is already a convention to use
clear as the name for the corresponding command ("remove all content from this object, so that it becomes empty"), therefore
empty is already unambiguous. On the other hand, Lisp dialects typically allow most punctuation in identifier names (because the code is basically already an AST, parsing is so simple that there is no need to forbid it). Therefore, the convention there is often to use
? at the end of the name.
On the other hand, in a method name like
isValid, that could just as easily be short for
pointIsValid rather than
isPointValid. The point is that
point was omitted because it is redundant; we already know that part, because it is a method on a Point instance.
Then again, there are entire communities of programmers that are happy to use languages other than English for their variable names (and many of them are very happy about modern languages and versions allowing them to use Unicode for source code files). Those languages may have different grammar, that in turn makes different conventions make more sense. (Of course, they will still be fighting against the fact that the language was designed by English speakers, so the syntax is probably designed with English grammar in mind.)
All of that said: use the existing conventions of the programming language (if there is an applicable style guide for the entire language), the project you're working on, the company you're working for, the libraries you're working with, etc. We don't want to "discuss" it on Stack Exchange (there is very little that anyone can point at, which is actual evidence and not just opinion), because we spend enough time discussing it with coworkers already.