viirya commented on PR #3115: URL: https://github.com/apache/arrow-rs/pull/3115#issuecomment-1316390606
> This is by design, as it would allow for unitialised memory. My suggestion is that `into_builder` would create a builder with the same length as the array from which it was created, i.e. `array.into_builder().finish()` would be a no-op. Does that make sense? > > You would then be able to implement things like `unary_mut` by doing something like > > ``` > let mut builder = array.into_builder()?; > builder.as_mut_slice().for_each(op); > builder.finish() > ``` This can work as like currently `unary_mut` does that iterating existing values as slice and mutating values as like. One minor disadvantage of making the same length for the builder is, you cannot use builder's APIs (`append_value` , etc.) to simply overwrite the existing values. Calling the builder's APIs like `append_value` will continue from the end of the existing array instead of mutating the existing values. The builder API cannot read existing values. So it cannot be used with an `op` which reads existing values and mutates that. From the point of view, the suggestion of `as_mut_slice` makes sense to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
