# Fix issue #19: Allow empty collection to byte array conversion

[scovl]

This PR fixes the issue where attempting to convert an empty vector to a byte array
produces an IllegalArgumentException instead of returning an empty byte array.

• Added explicit conversion support for empty Clojure persistent collections (vectors, lists, etc.) to byte arrays
• Made sure to handle only empty collections, rejecting non-empty ones with an informative error message
• Added comprehensive tests to verify the conversion works properly

The change is minimal and follows the maintainer's concern about "not having thought through all the implications of implicitly transforming nil into an empty byte-array." This PR specifically addresses empty collections while keeping the nil case separate.

With this change, code like (bs/to-byte-array []) now correctly returns an empty byte array instead of throwing an exception.

[KingMob]

Hi @scovl , thanks for putting this together.

I generally like us to write a clear problem statement, so we're all on the same page.

In particular, it would help if you could be the one to think through "all the implications of implicitly transforming nil into an empty byte-array." E.g., are people using nil differently from empty collection types? Do they inadvertently rely on any behavioral differences between them? Given the use of nil-punning in the Clojure community, is returning nil better than returning an empty byte collection of some type?

Some of these questions might require asking users, or looking at dependent code.

---

Also, the conversion from IPersistentCollection to byte-array-type can't be used as is, for a couple reasons.

First, throwing exceptions when non-empty is a time bomb waiting to happen.

The current byte-transforms code builds a cost-weighted, directed graph of pairwise transforms, and finds cost-minimal paths from the input type to the output type. None of the current logic is based on whether an input is empty or not, and there's many functions that work on the graph without inputs at all. If that conversion is added, byte-streams will report, and users will believe, that it works with generic clj colls now, and it will blow up (hopefully quickly).

Second, if we know what the type of a clj collection is, then it should already covered by the various (seq-of ...) conversions. It would be better to make sure those work with empty collections if they don't already, and that might be a more fruitful direction.

[scovl]

Hi @KingMob, thanks for the feedback. I understand your points and have closed the PR.

[KingMob]

@scovl I didn't mean to sound too harsh. I never want to dampen enthusiasm for contributing to FOSS!

[scovl]

I didn't mean to sound too harsh. I never want to dampen enthusiasm for contributing to FOSS!

@KingMob Don't worry. I actually liked your approach (exceptionally because I come from java) and it forces me to keep studying.