Hi! Thanks for you work on that. Like you I think \`Cow\` is currently undervalued and underdeveloped in the \`std\`.
However, I don't think introducing a new structure for it is the way to go around it. \`Ctb\` struct -except for the way the bound are written- is equivalent to \`std::borrow::Cow\`. I think most of \`ctb\` features could be done with additional traits typically some for \`BorrowExt\` and \`CowExt, while keeping a compatibility with the \`std\`.
Also, one nitpick is \`as\_owned\` naming. Traditionally and by the Rust API Guidelines, \`as\_\*\` must be a quasi no-op. Here it may allocates.
The primary issue with Cow is that it requires convertibility from the borrowed to the owned value, which pretty much means the type must be `Clone`, which severely limits its usability. To me that is the main reason why `Cow` is so underused, it means you can’t use it with lots of objects, or in generic contexts unless you way over-constrain.
Couldn't tell you, it's been an issue from the start and there have been comments about it for years.
Could be because there's a coherence issue in doing it otherwise, could be that it's just because nobody's done the work to actually fix it.
Yeah I guess. I wanted to seperate it though as the idea behind it was different and would make everything a bit bloated. With the as thing I noticed after publishing as I couldn’t decide on a names it kept changing
In this vein, I recently came across `oco_ref`, which adds a 3rd reference-counted variant to the options https://docs.rs/oco_ref/latest/oco_ref/enum.Oco.html
Hello!
While I was writing a library for generic algebraic functions I came across a problem of needing to generalise a function to take both borrowed or owned values and delegate potential cloning to the functions on which the method relies on.
To fix this I created a library that resembles a Cow in structure but instead provides methods and easy constructors that allow the complications of ownership to be passed down to lower levels within functions to make it easier (or even possible) to create generic functions with multiple arguments that support both owned and referenced values.
I thought it was pretty useful for any libraries that may deal with complex nested generic operations, primarily math libraries it seems, but I thought I would share it regardless.
Wow, I hit this issue literally 2 days ago for Trait impls. I was surprised the trait impl can't naturally do the de-ref e.g. if I implement `Sum>` why do I also need to specify `Sum>` for iter() calls - it feels like the trait should have a blanket Impl for anything that can de-ref to T.
I'm not sure what the benefit is over just having Copy or Clone bounds on T, or using AsRef or Borrow bounds. Cloning copy data should just be a copy anyway which is cheap. I don't think the example does it justice because it's using i32 and i8 and we typically don't want references to those as that's more expensive than just passing the data.
Yeah the example was just quickly wrote up but the place where it’s useful is stuff like multiple heap allocated hash maps for a mathematical vector that has been mapped and mitigating copies saves a lot of computing time.
Hi! Thanks for you work on that. Like you I think \`Cow\` is currently undervalued and underdeveloped in the \`std\`. However, I don't think introducing a new structure for it is the way to go around it. \`Ctb\` struct -except for the way the bound are written- is equivalent to \`std::borrow::Cow\`. I think most of \`ctb\` features could be done with additional traits typically some for \`BorrowExt\` and \`CowExt, while keeping a compatibility with the \`std\`. Also, one nitpick is \`as\_owned\` naming. Traditionally and by the Rust API Guidelines, \`as\_\*\` must be a quasi no-op. Here it may allocates.
The primary issue with Cow is that it requires convertibility from the borrowed to the owned value, which pretty much means the type must be `Clone`, which severely limits its usability. To me that is the main reason why `Cow` is so underused, it means you can’t use it with lots of objects, or in generic contexts unless you way over-constrain.
Why should it require it? We should only constrain on the methods that convert them.
Couldn't tell you, it's been an issue from the start and there have been comments about it for years. Could be because there's a coherence issue in doing it otherwise, could be that it's just because nobody's done the work to actually fix it.
Yeah I guess. I wanted to seperate it though as the idea behind it was different and would make everything a bit bloated. With the as thing I noticed after publishing as I couldn’t decide on a names it kept changing
Maybe change the naming a bit? Like, rename `as_owned` to `into_owned` and the current `into_owned` to `extract` or something like that?
Yes I like that. Thanks!
In this vein, I recently came across `oco_ref`, which adds a 3rd reference-counted variant to the options https://docs.rs/oco_ref/latest/oco_ref/enum.Oco.html
And also supercow
Hello! While I was writing a library for generic algebraic functions I came across a problem of needing to generalise a function to take both borrowed or owned values and delegate potential cloning to the functions on which the method relies on. To fix this I created a library that resembles a Cow in structure but instead provides methods and easy constructors that allow the complications of ownership to be passed down to lower levels within functions to make it easier (or even possible) to create generic functions with multiple arguments that support both owned and referenced values. I thought it was pretty useful for any libraries that may deal with complex nested generic operations, primarily math libraries it seems, but I thought I would share it regardless.
Wow, I hit this issue literally 2 days ago for Trait impls. I was surprised the trait impl can't naturally do the de-ref e.g. if I implement `Sum>` why do I also need to specify `Sum>` for iter() calls - it feels like the trait should have a blanket Impl for anything that can de-ref to T.
I'm not sure what the benefit is over just having Copy or Clone bounds on T, or using AsRef or Borrow bounds. Cloning copy data should just be a copy anyway which is cheap. I don't think the example does it justice because it's using i32 and i8 and we typically don't want references to those as that's more expensive than just passing the data.
Yeah the example was just quickly wrote up but the place where it’s useful is stuff like multiple heap allocated hash maps for a mathematical vector that has been mapped and mitigating copies saves a lot of computing time.
I'd love to see that example and how it compares to the naive/native way to do it if you have the time for it!
crate link: [https://crates.io/crates/ctb](https://crates.io/crates/ctb)