Provide blanket From impls for homogeneous collections
- Dominant language
- Rust
- Stars
- 1.4k
- Forks
- 162
- PR merge metrics
- No merged PRs in 30d
Description
Hey!
First of all thanks for your work!
Could you imagine adding `From` impls for the `Array` and `Map` Value variants for homogeneous collections of elements that already are `Into`? This would improve the API ergonomics quite a bit in common (well, common for me...) cases. Coherence does not let me provide these impls in a different crate.
As a POC, have a look at [this playground](https://play.rust-lang.org/?gist=5b402cbce698f0eef661eb8045fdc8a1&version=stable&mode=release&edition=2015), which provides these impls for a simplified version of `Value`. Of course, those impls need to allocate a new `Vec`.
Now, they conflict with the existing `From>` and `From>` impls. Replacing them might not be opportune, since the existing impls do not allocate, which is an advantage. Othoh, I'd argue that the allocation happens anyways at the call sites, so that might not be a problem. What do you think? Specialization would help, of course :) But maybe there's another way around that in this case?
Anyways, thanks for reading. If you consider to do this, I'd be open to send a PR.
(e) I'd like to put up another argument for the "new" impls. Firstly, I went through the creates dependent on rmpv. I'd say it was inconclusive due to too few crates :) But many might depent on it transitively, e.g. my crate did not show up, although I'm using rpmv through the reexports in neovim-lib.
Now, what I wanted to say was that the "old" impl can easily be replicated. Say you have a `v: Vec` and want to avoid the alloction of the "new" impl, you could just use `Value::Array(v)` instead of `Value::from(v)`, so you're not locked into having a superflous allocation, if for some reason you're handling a `Vec` without having handled the "original" `Vec>` before.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.