The consensus on Are library design questions on-topic? appears to be that library design questions can be on-topic, and in general I agree with that. Some aspects of programming language standard libraries are undeniably language design questions.

But surely not all questions about a language’s standard library ought to be on-topic: plenty of languages have exceedingly large, “batteries-included” standard libraries, so if we allowed questions about any aspect of a standard library, we’d have to consider questions about, say, the design of an API for an MD5 implementation on-topic. This doesn’t seem like something that has very much to do with programming language design.

What criteria can we use to distinguish these on-topic standard library questions from off-topic ones? Ideally, we need to have a rule of thumb that leaves as little to subjective opinion as possible, since otherwise it cannot be consistently applied.


2 Answers 2


In 2014, the US Supreme Court decided that taking an existing idea and simply “doing it on a computer” was not sufficient to produce a separately-patentable new idea. In a similar spirit, perhaps we can apply the following rule of thumb: library design questions are not automatically on-topic simply because someone, somewhere, chose to “do it in the standard library”. In other words, if all answers could apply equally well, without modification, to the same API in a non-standard library, it is not a language design question.

Let me present some examples to illustrate this reasoning:

  • How does the C++ Committee generally decide what does or doesn't go in its standard library?

    This question is on-topic because it is specifically about the challenges of deciding which things to include in a language’s standard library, which has different considerations from what to include in other, non-standard libraries. Therefore, the answers would no longer apply if the question were about some other library, so the question is a language design question.

  • Why does Java's HashSet have an underlying HashMap, not the other way around?

    This question is off-topic because it is purely a question about data structures. In many languages, these sorts of data structures do exist separately from the standard library, but the answer to the question would be identical if asked about those libraries. So this is not a language design question. (This does not mean the question has no value. It just means it is off-topic.)

  • Are there any disadvangates to requiring sincos() type functions?

    This question is on-topic because the functionality being discussed cannot easily be defined in a separate library since it is platform-dependent. Therefore, it is a question of what primitive operations the programming language provides, and it is therefore a language design question.

  • Why doesn't C's standard library have functions for searching memory like strings?

    This question is off-topic because it argues that a memmem function for linearly searching memory ought to exist due to the existence of a strstr function for linearly searching strings. This style of argument could apply equally well to any library, so the question is not a language design question. (Again, this does not mean the question has no value.)

  • What are the pros and cons of an Option type in comparison to nullable types?

    This question is on-topic because even though it may be possible to define an Option type in a separate library, the choice of whether or not to include one impacts aspects of the language itself, such as the type system or conditional assignment. The answers would change if the question were about the pros and cons of using an Option type defined in a separate library, so this is a language design question.

There is some wiggle room here, but on the whole I think applying the rule to each of these questions is relatively clear cut. The question of whether the answers themselves would have to change were the functionality in a separate library is a simple criterion that is removed from the question of what ought to go in a language’s standard library, which is extraordinarily subjective.

  • $\begingroup$ I agree with this answer, but I think "if all answers could apply equally well, without modification, to the same API in a non-standard library" is not an easy test to apply to a question. Perhaps there is some answer that would not apply equally well, but the close-voters didn't think of that answer. $\endgroup$
    – kaya3
    Commented Jun 28, 2023 at 22:00
  • $\begingroup$ @kaya3-supportthestrike I agree with that, but I think that is the nature of close reasons, and it is why we require consensus. For example, there is always the potential for a question to be closed as being “primarily opinion-based” even if there is, in fact, an objective answer (and this does happen sometimes). Questions can be reopened. I think some rule of thumb is necessary for the reasons outlined in the question, and this is the best one I’ve come up with so far. But maybe there are better ones! $\endgroup$
    – Alexis King Mod
    Commented Jun 28, 2023 at 22:04
  • $\begingroup$ One area you have left gray is questions that would fall into the "is it better to be batteries included?" category. They generally have the problem of being subjective and/or about community building but within the group there are some good questions. $\endgroup$ Commented Jun 29, 2023 at 14:27

I think there are three significant differences between a standard library and a third-party library:

  1. Every user of the language is stuck with the standard library, because even if they use a third-party alternative in their own code, other third-party libraries that they use are likely to interface with the standard library somehow. So a standard library has to "please everyone".
  2. Some aspects of a standard library may be intrinsically linked to the language's semantics. For example, the Java's String class has specially-defined behaviour with the + operator, as does Rust's Result enum with the ? operator (though, I think, the Rust designers plan to open this operator up to user-defined types).
  3. Some functions in the standard library may need native implementations in a compiler or interpreter, because their behaviour is not otherwise implementable using other language constructs.

Therefore I propose that a standard library question is on-topic if one or more of the above considerations is relevant to the question. This is almost equivalent to Alexis King's proposed criterion, but I have tried to list the ways in which answers might not "apply equally well" to a third-party library, to make that criterion more concrete.

  • $\begingroup$ +1; I think this is a good enumeration of the sorts of things that make standard library questions language design questions. $\endgroup$
    – Alexis King Mod
    Commented Jun 28, 2023 at 23:02
  • 1
    $\begingroup$ I would add one more thing to point 2: A compiler is (in general) allowed to assume that the standard library is always present, and is therefore allowed to generate code that calls it. An example is assignment of large structs in C, which could be implemented as a call to memcpy/memmove. $\endgroup$
    – Pseudonym
    Commented Jun 29, 2023 at 2:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .