I think as this is a breaking change regardless, we should probably just add the length as an explicit argument and avoid potential errors/panics. I don't really feel strongly though, I personally think empty StructArrays are something the arrow spec probably shouldn't permit, but that ship has sailed...

Perhaps @alamb has thoughts on the matter

Ah, as you were typing that I saw the suggestions from #6732 which suggested adding try_new_with_length (yet another alternative). I've implemented that and changed the docs for try_new to encourage try_new_with_length but I agree it might be more straightforward to force users to do the inference themselves.

which suggested adding try_new_with_length (yet another alternative)

I'm personally less a fan of this, as it isn't materially different from the current state of play - where there are multiple alternative methods.

I guess I was thinking something along the lines of

pub fn try_new(
        len: usize,
        fields: Fields,
        arrays: Vec<ArrayRef>,
        nulls: Option<NullBuffer>,
    ) -> Result<Self, ArrowError>

That being said, this would be potentially quite a disruptive change, and I am not sure how common empty StructArray actually are, I can't help feeling most of the time they'd arise from a deficiency in a projection system, rather than someone actually creating them...

For an additional data point, RecordBatch::try_new is consistent with StructArray, and so not making this change might be more consistent. I don't really feel strongly on this, which I guess would be an argument towards not making a breaking change here... I'll let others weigh in.

I would push for the breaking change honestly..

Here's another example: #7447

I've rebased. It seems the consensus is leaning towards making this change now. If there are no other suggestions by Friday I will merge.

🚀 -- thanks @westonpace and everyone else

I am adding an API change label to this PR to make sure it is highlighted in the release notes - I think it is fine to release this in a minor release (and not have to wait for the next major release)

IMO I'd have considered this to be a breaking change, as the StructArray::new constructor now panics with input considered valid as of 55.0.

In pyo3-arrow I have a test that checks I can import an empty RecordBatch which goes through this code path, which uses StructArray::new and now panics.

Ideally I'd like to declare my dependency at 55.0 to let downstream users use either 55.0 or 55.1, but I can't use the suggested workarounds of try_new_with_length because that didn't exist in 55.

I figure I'll just bump my requirement to 55.1 and that'll be the least painful way to handle this.

We can also create a 55.0.1 release and backport the try_new_with_length method if that is better

Given how much work it looks like every time you make a release, I really don't want to make you make a release if you don't need to 😅

In kylebarron/arro3#328 I bumped to require 55.1 and that's fine with me.

This also seems to have caused a panic when filtering struct arrays:

• Fix filter_record_batch panics with empty struct array #7539