I've tried a few approaches, including the auto-ref based one [1], but no luck so far. I'm thinking to explore std::any and downcast_ref and see if that is more promising.
[1]: https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md On Tue, Jul 28, 2020 at 10:48 AM Andy Grove <andygrov...@gmail.com> wrote: > Yes, that is my understanding too (specialization being the main blocker). > > I will start experimenting with removing one of the specializations over > the next few days and see what I learn. It would be good if others want to > try this too and we can swap notes. > > > > On Tue, Jul 28, 2020 at 11:37 AM Chao Sun <sunc...@apache.org> wrote: > > > 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. > > > > > >
