# \`NonEmptyArray\`

**URL:** <https://es.discourse.group/t/nonemptyarray/2216>\
**Category:** 💡 Ideas\
**Tags:** proposal\
**Created:** [November 17, 2024, 3:08pm UTC](https://es.discourse.group/t/nonemptyarray/2216 "2024-11-17T15:08:08Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![Rudxain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/rudxain/32/2272_2.png) [@Rudxain](https://es.discourse.group/u/Rudxain)\
**Post date:** [November 25, 2024, 5:59pm UTC](https://es.discourse.group/t/nonemptyarray/2216/5 "2024-11-25T17:59:08Z")

</div>

> [@ljharb](#):
>
> What problem is this attempting to solve?

As per the links I shared, there are cases where a piece of code requires a collection of 1-or-more values. Even ES has defined methods with that requirement (`reduce`). Perhaps some DOM or Web API requires one? (I tried searching, but couldn't find an example)

I'm aware `a.length > 0` is enough, but the point is to not have to check every-time, but to "rest assured" that the list won't be empty at any point in the program. For further reference about the general concept, see:

- [Type-driven parsing](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate)
- [custom validation types in Rust](https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html#creating-custom-types-for-validation)
- [`newtype` pattern](https://doc.rust-lang.org/rust-by-example/generics/new_types.html)
- ["Ghosts of Departed Proofs"](https://kataskeue.com/gdp.pdf)

However, I can't come up with a "compelling enough" argument in favor of this specific `class`. I'm afraid this is one of those "greater than the sum of its parts" situation:

- Doing something on the ES side won't be useful enough to justify the complexity cost.
- Doing something on the TS side alone won't yield satisfying results.
- If there was some sort of "collaboration" between ES & TS (or if ES defined a static type-system), there _could_ be enough reasons to justify the addition.

> [@theScottyJam](#):
>
> Is this mostly about having an array type that can't be empty

Yes! (but the idea could be extended to other collections, such as `Set`) I've been thinking more, then thought "What's the point of forbidding sparsity if the array can still contain `undefined`?" So I think it'll be more useful if inserting `undefined` `throw`s. We could also forbid `null`, but that may be too extreme.

If this happens, it'd make more sense if the N.E.A. API was similar to that of `Map`, which would make it easier to poly-fill (no need for `Proxy`). But if `length` -\> `size`, then it would no longer be "array-like" :( . That may need to happen anyway, as an N.E.A. could have no hard-coded theoretical limit, which would [require `size` to be a `BigInt`](https://es.discourse.group/t/github-js-choi-proposal-bigint-math-draft-specification-for-supporting/942/16)

> [@aclaymore](#):
>
> These would also need to throw when there is only one item left

That's what I meant! I assumed the array can't contain `undefined`, so the only way to return it is if there's 1 element.

> [@aclaymore](#):
>
> Both behaviors could be surprising

Yep, I agree. An alternative would be to add `toPopped` and `toShifted`, which would shallow-clone the array, potentially returning a classic array.

---

_[View the full topic](https://es.discourse.group/t/nonemptyarray/2216)._