Leaderboard

My preference would be to start simple and only address the most basic, and widely useful, functionality of splitting the input string into an array of single characters. If it's determined that people would benefit from additional functionality, it can always be added later. But, we don't want to risk adding features that people won't need, since every feature must be designed, documented, tested, and maintained, which takes development resources away from other high-value features/activities.

Just so we are all on the same page, the change is not as small as advertised (not that it is that big a deal). The number of iterations must be calculated, handling the case where the data size is not commensurate with the chunk size (padding or clipping). The offset must be multiplied by the chunk size as well. These changes add significant overhead to the single char case, too much to justify a simple change IMO. You could add a comparison and handle the single char case separately. A Chunking tool would be useful but it should be polymorphic IMO. Certainly a candidate for an XNode, but my philosophy is that XNodes are fun to play with, but they have a lot of baggage when it comes to distributing them. Someday NI may allow us to place one at the top level in a Packed Project Library (that would be sweet) so we could distribute them as a single file. I would suggest a simple polymorphic VI that handles the usual suspects (strings, ints, floats, booleans). I lean against bloating this one. I was already less enthused about it once I determined that the obvious method was also the most efficient.

I know it is a small change, but I don't think that is a good enough reason to justify a(ny) feature.