That's funny after reading the comments from the 1.0 release on HN last night I
have been researching on this too. It really is the main feature users want so
we should prioritize it. Personally, I have avoided this as I remember living
without specialization (macros) but as Andy noted I think
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 An
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 Cha
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
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
