# \`isNotEmpty\` on Array

**URL:** <https://forums.swift.org/t/isnotempty-on-array/15228>\
**Category:** Pitches\
**Created:** [August 14, 2018, 1:59pm UTC](https://forums.swift.org/t/isnotempty-on-array/15228 "2018-08-14T13:59:34Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [August 14, 2018, 11:33pm UTC](https://forums.swift.org/t/isnotempty-on-array/15228/15 "2018-08-14T23:33:55Z")

</div>

> [@nuclearace](#):
>
> @ben-cohen Do you think we should have some notes on how standard library changes should be thought out. Possibly posing some questions for potential pitchers?

Thanks for bringing this up. I've been thinking about this recently, especially in the light of a large number of "trivially composable" proposals that have been brought up recently. The problem is mainly the relative weighting of the criteria we've discussed. Readability improvements and _minor_ performance and correctness optimizations are being used as the main criteria, whereas I feel like major performance wins and _really hard_ (but still relatively common) problems to solve correctly are being underweighted.

I think there's a real risk with the current pitches that we end up with a standard library populated with huge quantities of sugar and not enough protein. I feel like we need to refocus on key algorithms that are important and hard to write correctly, rather than minor nice-to-haves which are (sometimes) more common, but also very easily written. A standard library that is missing stable sorting and partitioning, rotation, permutation, and binary search, but does have `notEmpty`, `id`, `isEven`, would be pretty unfortunate.

> [@gwendal.roue](#):
>
> Could this apply to `isEmpty` ? In the light of the first rule of the [Swift API Design Guidelines](https://swift.org/documentation/api-design-guidelines/), "Clarity at the point of use", which one below is the best?

I see this as guidance _when adding something_ about what to call it, and not guidance as to what to add. That is, once you have decided to add an `allSatisfies` method, that naming guidance is how you decide to call it that and not `all` or `contains(only:)`. It isn't an encouragement to add synonyms or trivially composable methods to the standard library. Those can sometimes aid readability – but they harm the usability of the library by bloating it, making it hard to use and navigate.

> [@dylanmaryk](#):
>
> That's fair. I simply think this would be some nice syntactic sugar, similar to toggling a Bool.

I think there's an important difference. The motivation for toggle was the need to duplicate long expressions (`path.to.something.over.here = !path.to.something.over.here`) as well as avoid the risk of typos in that long expression. Neither of these arguments materially apply to `!isEmpty` over `notEmpty`.

---

_[View the full topic](https://forums.swift.org/t/isnotempty-on-array/15228)._