Wow, I didn't think this was possible without
This is great! Your API is somewhat similar to the vecstorage crate, which solves the same problem as
I've learned a lot from analyzing your code, thanks for taking the time to write it!
I've somehow gotten the (wrong) impression that raw pointers can only be used for
Sized types. I guess I misread some compiler error some time ago and never again tried to create a fat raw pointer. Thanks to your code I know now that this is possible after all. I've also double-checked in the reference: https://doc.rust-lang.org/stable/reference/type-layout.html#pointers-and-references-layout. Raw pointers can be just as fat as references! And both have the same layout.
This new-found knowledge allowed me to improve the implementation of
rsor::Slice: https://github.com/mgeier/rsor/pull/12. I think it is now safer and simpler, which is great!
Yes, it definitely solves the given problem. However, I don't think the API is as nice.
It works very well for the initial code example, but I'm more interested in the situations which I've mentioned in the Common Use Cases section. I guess in this case
slice_borrow.extend(...) can be used with iterators, but it's slightly more convenient to have a one-liner like
I'm not sure whether an abstraction similar to from_refs() could be made?
Another shortcoming of the fact that the
Vec is returned to the user is that the user has to be more careful about where the scope of it ends.
I first thought you added the second scope in the example just for symmetry, but it turns out that it is actually necessary, because without it the compiler complains:
mutable borrow might be used here, when `strings` is dropped and runs the `Drop` code for type `SliceBorrow`
This limitation doesn't exist for
Why? Because the language doesn't guarantee this specialization to be present?
I guess this will depend on how easy those allocators will be to use. I'm looking forward to them!
But maybe some additional custom abstractions will still be helpful ...