BoundsError or MethodError for some heterogenous collections

[yha]

unzip( [(1, 2), (3, 4)] )                        # OK
unzip( x for x in [(1, 2), (3, 4)] )             # OK
unzip( [(1, 2), ("a", "b")] )                    # OK
unzip( x for x in [(1, 2), ("a", "b")] )         # MethodError: no method matching widen_column(::Base.HasLength, ::Int64, ::Int64, ::Vector{Int64}, ::String)
unzip( [(a=1, b=2), (a=3, b=4)] )                # OK
unzip( x for x in [(a=1, b=2), (a=3, b=4)] )     # OK
unzip( [(a=1, b=2), (a="a", b="b")] )            # BoundError: attempt to access 0-element Unzip.Rows{Tuple{}, 1, Tuple{}} at index [1, 2]
unzip( x for x in [(a=1, b=2), (a="a", b="b")] ) # MethodError: no method matching widen_column(::Base.HasLength, ::Int64, ::Int64, ::Vector{Int64}, ::String)

[bramtayl]

Hmm, to be honest, I'm surprised things with named tuples are working at all!

The method errors seem to be due to a bug:

function widen_column(::HasLength, new_length, an_index, name, column::Array, item) as an extra name field. Would be good to fix and add a test to catch this.

The BoundsError is a bit trickier. The package assumes that if a collection has an eltype, then we can figure out what the row types will be.
That's not the case here. If we can't figure out the row types from the eltype, we should just ignore the eltype all together.

[yha]

Hmm, to be honest, I'm surprised things with named tuples are working at all!

I use unzip with named tuple all the time! Works great except when I hit this issue, usually due to missing values in some of the elements causing an abstract container type.

[bramtayl]

Sweet! Glad to you know you find the package useful