[ncmncm]

You don't use the "sort pattern". You call the sort function, because it exists.

In C, you would code up, in place, an example of the "hash table" pattern, but more expressive languages have hash dictionaries in the library that are as fast as, or faster than, you could afford to code in place.

If your language can't properly express a "maybe" monad, you can cobble something together to use instead, and mention that in a comment. But it's only a pattern because you don't have it.

[mikekchar]

I'm afraid I didn't express myself well. Where I think we're not aligning is that you are under the impression that I'm using the same definition of pattern that you are. It was my intent to express that I disagree with your definition.

It's important to understand that a pattern is a solution to a problem along with contexts in which it is both appropriate and inappropriate. To document a pattern you need: a description of a problem, a description of the solution, contexts in which this solution is appropriate, contexts in which this solution is inappropriate. If you read the early literature on patterns and pattern languages (Beck and Cunningham's initial paper, or really any of Coplien's writings), I hope it will be more clear.

"Sort" and "hash table" are not patterns. They are simply solutions without problems. They are also not specific enough to discuss various contexts. When is it inappropriate to sort? That's a meaningless question without a lot more information. Sorting may indeed be a solution to a problem, but it is not in itself a pattern.

We could say that the maybe monad implements a particular pattern for representing optional data. It is, however, not the only method for representing optional data. There are many others. The point is to be able to understand which one you should use in which context. That it can be implemented in a library is fantastic (less code for you to write), but that was never the point of design patterns (hence the word "design"). The point was to give you a vocabulary with which to discuss the merits of various solutions to problems and to pick appropriate ones for your circumstance.

[lmm]

Do you consider the things in the "gang of four book" to be patterns? If so, how do you distinguish them from something like "sort" or "hash table", since they are also solutions without problems? If not, I'd argue that your definition of pattern doesn't match the present meaning.

[ncmncm]

"Pattern" comes from the Gang of Four book, by way of confusion about an entirely different concept from architecture.

The book has not aged well. Its vocabulary has turned out to be decreasingly useful. I go for many months at a stretch without encountering any reason to mention any of them. The only names that come to mind, at the moment, are the "visitor" and "pimpl" patterns, only the latter of which I have used in the past decade, and that because it is imperfectly supported by the library template std::unique_ptr<>.

That is not for lack of discussion of choices among possible solutions to problems. Notably, most on https://cpppatterns.com/ are just library components.

[mikekchar]

Pattern comes from here: http://c2.com/doc/oopsla87.html It even says so in the GoF book.