`StrictArray`

💡 Ideas
2

My problem with introducing a new array type, is that creates a schism in the data-types we use. If I'm making a library, and I want an array to be passed in as an argument, what should I do?

  • Only support the old array type, because that's most prevalent and easy-to-create (any time you use the array literal syntax [...], you'd get the old-style array)
  • Only support the new array type, because that's the safer one to use? Though this may require end-users of my API to auto-convert this old-style arrays to this new-style one. I myself may be required to convert the new-style back to old-style when calling other third-party library functions. So, lots of conversions would be happening.
  • I could support both styles, but then I, as a library author, don't get to reap any of the benefits of the new-style array - I still have to always assume that out-of-bounds access does not throw an error, etc.

So we do have to weigh the pros of adding this new kind of Array with the major con of this kind of divide between people using the two styles.

I also feel like a number of these points could be done by updating our existing array class with new helper functions, instead of making a new array type altogether. For example:

  • We already have Array.of() that you can always use instead of the Array constructor.
  • Perhaps we could discuss adding some sort of .strictAt(index) function that requires the index to be an in-bound UInt32 (I sort of doubt they'd actually add this, because the precedence has always been to coerce, and to provide undefined when the thing does not exist, but still, if we were to add this functionality, I think it would be better on our existing Array class instead of in a new one).
  • The withLen() function sounds like a nice-to-have that isn't necessarily related to strict arrays, and could be a proposal of its own that we just add to the Array class?

Your second point about not allowing empty slots in an array would be nice to have, but perhaps that too could be solved by adding features to the original Array class, such as: An assertNoEmptySlots() methods you can call on an array whenever you want, to cause it to throw an error if the array has empty slots. You can call this on arrays that enter your library, and then make sure you don't do anything silly that would cause empty slots to be added to that array. A function like this would actually be really nice to have.

3 Likes