Thanks Andy for starting the thread. Agree that supporting stable Rust should be one of the top priorities.
Instead of creating a new crate, I'd prefer to make the switch in-place in the current crate if possible. A major part of the current code base, such as compute kernels, ipc, etc., is built upon the existing APIs. Making a new crate probably means a lot of re-implementation on these. Many apps probably need a stable parquet crate together with arrow too which means we'll need to do the same for that. To my understanding the main blocker is specialization which is used by both arrow and parquet (packed_simd can be optional?). If this is true perhaps we should first explore a way to remove this without API change. I haven't found a way yet but I don't think it is impossible. On Tue, Jul 28, 2020 at 9:43 AM Andy Grove <andygrov...@gmail.com> wrote: > After seeing more feedback on this topic recently, I've been thinking about > this some more and wanted to make a proposal for how we can start to > address this. > > It seems that we do have some code today that we could relatively easily > support on stable Rust, such as the Buffer struct. What if we were to > extract those parts out into a crate that can build on stable Rust as a > starting point? > > We could then potentially start designing a new Array API in that crate > that can work with stable, while also maintaining the nightly-only API in > the other crate? > > I think I probably speak for many of the Rust committers when I say that I > understand Rust much better now than I did when initially designing the > APIs and I think it would be good to take another look at how we might want > to implement this. > > Thanks, > > Andy. >
