It is not the official goal.
There are temporary practical reasons prior to ABI stability for keeping the standard library small, because it must be shipped with every app. Once the library ships with the OS, this is no longer a concern.
Method proliferation can be a problem. If every type is bristling with overlapping or barely-useful methods, the API becomes bewildering and hard to use. This is more of a concern when extending broad protocols like
Collection, less so when extending concrete types like
Consistency is also a mitigating factor here. If there is a
Sequence and a
Dictionary, then it is helpful to users working with the API to follow through with
Obviousness of implementation is not necessarily a reason to exclude an addition. There are many methods in the standard library that have an obvious implementation. "Trivially composable" has been used as the term for avoiding gratuitous additions – but the word trivial is important here. It refers to compositions such as
!isEmpty rather than operations that require a
for loop or multiple compound statements.
Some criteria to consider for an addition of a method to the standard library are:
- does it aid readability?
- is it a common operation?
- is it trivially composable?
- is it consistent with existing methods?
- does it help avoid a correctness trap?
- does it help avoid a performance trap?
- alternatively: might it encourage misuse?
- can it be more efficiently implemented internally within the std lib?