Comments (5)
This is a limitation of Deref
. There is no DerefMove
. There's nothing I can do about it, sorry. An alternative would be to define inherent methods on BString
, but I'm not sure I want to go down that route.
But I note that strictly speaking, the title of your issue is wrong. You can of course move out of a BString
:
use bstr::BString;
fn main() {
let x = BString::from("foo");
let y = <Vec<u8>>::from(x);
println!("{:?}", y);
}
from bstr.
There's nothing I can do about it, sorry.
Can you not implement the into methods on BString and forward them to the inner bytes
?
impl BString {
pub fn into_string_lossy(self) -> String {
self.bytes.into_string_lossy()
}
}
I note that strictly speaking, the title of your issue is wrong.
OK, I updated the title to not be wrong.
from bstr.
Can you not implement the into methods on BString and forward them to the inner
bytes
?
If you quoted the rest of that paragraph...
An alternative would be to define inherent methods on
BString
, but I'm not sure I want to go down that route.
To elaborate:
- I would like to keep the types simple and small wrappers.
- The maintenance overhead of copying every method that takes
self
by value is annoying. - Users looking at the docs for
BString
may very well be confused by the fact that has a subset ofByteVec
methods as inherent methods but not others. It's probably a confusion that's easily cleared up with docs or what not, but it's still a cost IMO.
I'm not saying "no," but those are my thoughts currently.
from bstr.
If you quoted the rest of that paragraph...
Ugh, I’m sorry about that. I’m having one of those days.
I agree that it is crappy for maintenance to have to reimplement methods (this is one of my own top pain points writing newtypes). Hopefully rust-lang/rfcs#997 eventually eliminates the need to do it, though I don’t see any indication that that’s coming soon. At least implementing forwarding methods is simple enough to do by macro, so boilerplate would be minimal, and the docs on the methods could be similarly rote (“Consumes the inner Vec by forwarding to [`ByteVec::<into_whatever>`].” or something).
To your point about user confusion, as a user I would say it is probably more confusing to have a BString
type which owns its contents but can’t be moved-from in the way the API suggests should be possible (via the auto-derefed into
methods). Part of this is that Rust’s diagnostic here is confusing; there is an open issue about that at rust-lang/rust#45515.
Ergomonically, I feel like it is not great for a consumer to have to e.g. Vec::<u8>::from(foo).into_string_lossy()
. It’s also not an obvious solution (at least it was surprising to me), and so I suspect some people—especially those who are newer to Rust—will end up doing something bad like (*x).clone()
to escape a seemingly impossible situation. Since I was already writing a wrapper myself, I just ended up replacing BString
with Vec<u8>
instead.
If you really feel like reimplementing the into methods on BString
is a wrong solution, maybe a compromise would be to just add a method that gives a clear way to unwrap it?:
pub fn into_vec(self) -> Vec<u8> {
self.bytes
}
Thanks for replying so quickly, and apologies again for my brain dysfunction.
from bstr.
Those are all fair points. I suppose if we could do this will minimal fuss using a macro, then I might be on board with it.
Adding more explicit constructors and eliminators to the APIs of BStr
and BString
are also something I'd be amenable to, independent of your specific issue.
from bstr.
Related Issues (20)
- Character-oriented slicing and length APIs HOT 2
- Consider using `once_cell` instead of `lazy_static` HOT 3
- Ensure crate abides by the Unicode Data Files and Software License HOT 4
- bstr pulls in serde when `serde` feature is not specified HOT 6
- bstr-bench Cargo.lock out of sync
- Can the MSRV be lowered to 1.57 (or lower)? HOT 3
- Clarify None case in bstr::decode_utf8 HOT 1
- Feature request: `impl Deserialize for Box<BStr>`
- bstr 1.3.0 with `impl AsRef<BStr> for BStr` breaks some folks downstream HOT 1
- candidate versions found which didn't match: 0.2.17, 0.2.16, 0.2.15, ... HOT 5
- Possible panic safety issues in insert_str HOT 2
- Complementary ByteSlice functions addition - find_not_byte / rfind_not_byte HOT 1
- Use clippy in CI? HOT 2
- Intradoc links are broken when building with no default features HOT 3
- re-enable miri tests
- Accept array of str for split_str HOT 1
- remove `Borrow<BStr> for String` impls (and similar) in a semver compatible release HOT 9
- Add unescape_ascii fn HOT 4
- Display implementation doesn't respect Formatter options
- `bstr::Split` should implement clone. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bstr.