4 ms·

There's always a lot going on in every line of Rust and I respect that. But a lot of it is boilerplatey. E.g. this AsRef business - the argument is that it help

There's always a lot going on in every line of Rust and I respect that. But a lot of it is boilerplatey. E.g. this AsRef business - the argument is that it helps performance, but I hope that sometime in the future it would be much easier and cleaner to express things like "I want two arguments of any type I can transform to an owned string" without adding a bunch of explicit generic arguments, or even "I want a hashmap with keys and values of any type I can transform to an owned string", allowing people to use your api without adding/removing .to_owned() after strings every time they change something, or all this iter-map-to_owned business. And no, I don't mean it as having java-like semantics. Semantically such functions should stay generic over the types. There's no reason not to sugar it over, though

oconnor663 4y ago
> I want two arguments of any type I can transform to an owned string Since Rust 1.26 you can write this: fn foo(x: impl Into<String>, y: impl Into<String>) { ... } Which is almost exactly the same as this: fn foo<T: Into<String>, U: Into<String>(x: T, y: U) { ... }
- zozbot234 4y ago
  But this has the same flaw as the original code in OP, where you need a separate inner function to avoid excess monomorphization. What's wrong with just taking a String (or a ref to Path) and expecting user to add .into() at the calling site?
  - scottlamb 4y ago
    Basically you have the choice of adding a tiny bit of boilerplate in the caller, having monomorphization bloat, or adding lots of boilerplate to the callee. In general I'm with you: just stick the .into() in the caller. But this is pub std code, expected to be called from many many places, so they probably made the right choice to make it more convenient to call.
  - estebank 4y ago
    I do want to highlight a comment in passing in the OP: the team has plans (and some work) around accomplishing that optimization in an automatic way, without extra syntax, under the whimsical name of polymorphisation.
  - ssokolow 4y ago
    If it really matters, you could always use the #[momo] procedural macro by Andre "llogiq" Bogus, one of the big names in the Rust community: https://lib.rs/crates/momo https://lib.rs/crates/momo

oconnor663 4y ago

> I want two arguments of any type I can transform to an owned string Since Rust 1.26 you can write this: fn foo(x: impl Into<String>, y: impl Into<String>) { ... } Which is almost exactly the same as this: fn foo<T: Into<String>, U: Into<String>(x: T, y: U) { ... }

zozbot234 4y ago
But this has the same flaw as the original code in OP, where you need a separate inner function to avoid excess monomorphization. What's wrong with just taking a String (or a ref to Path) and expecting user to add .into() at the calling site?
- scottlamb 4y ago
  Basically you have the choice of adding a tiny bit of boilerplate in the caller, having monomorphization bloat, or adding lots of boilerplate to the callee. In general I'm with you: just stick the .into() in the caller. But this is pub std code, expected to be called from many many places, so they probably made the right choice to make it more convenient to call.
- estebank 4y ago
  I do want to highlight a comment in passing in the OP: the team has plans (and some work) around accomplishing that optimization in an automatic way, without extra syntax, under the whimsical name of polymorphisation.
- ssokolow 4y ago
  If it really matters, you could always use the #[momo] procedural macro by Andre "llogiq" Bogus, one of the big names in the Rust community: https://lib.rs/crates/momo https://lib.rs/crates/momo