> And there's a good chance we'll add auto-deref+autoref for function arguments, specifically so String will auto-slice to &str the same way ~str used to (although someone still needs to write up an RFC for this).
I would like the devs to clarify their support for this proposal, since I have seen little discussion regarding it. On Tue, May 27, 2014 at 10:17 PM, Kevin Ballard <[email protected]> wrote: > On May 27, 2014, at 1:55 PM, Benjamin Striegel <[email protected]> > wrote: > > What I was specifically curious about is why you seem to be against the > usage of the `Str` trait as a bound on the argument to the `captures` > method. > > > It adds unnecessary complexity, bloats the crate metadata with the > function AST, and complicates the type signature, with no real benefit. The > only thing that taking `<S: Str>` for an `arg: S` argument does is allowing > a String to be passed without calling .as_slice(). But the <S: Str> > solution moves the String into the function, rather than slicing it, which > means the calling function gives up ownership of the String. This is rarely > desired, and is likely to be confusing. > > We're also almost certainly going to implement Deref<str> on String > post-DST, which means slicing a String is a simple as &*foo. And there's a > good chance we'll add auto-deref+autoref for function arguments, > specifically so String will auto-slice to &str the same way ~str used to > (although someone still needs to write up an RFC for this). > > -Kevin > > On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard <[email protected]> wrote: > >> On May 27, 2014, at 6:05 AM, Benjamin Striegel <[email protected]> >> wrote: >> >> > The use of taking <S: Str> is for taking things like &[S], where you >> want to take both &str and String (such as in the other post about >> getops()). >> >> I wouldn't be bothered with leaving the API as-is, but I don't understand >> where this guideline is coming from. Can you elaborate? >> >> >> I don't know if there's any authoritative source for this, but it's been >> suggested in the past for other APIs. The basic issue is that &[String] >> cannot be freely converted to &[&str]; you need to allocate a new Vec for >> that. So if you have a &[String] and try to call an API that takes a >> &[&str] then you're doing extra work just to satisfy the type system. But >> the function in question doesn't actually need &[&str], it just needs a >> slice of things it can convert to &str. So if it takes <S:Str> &[S] then >> you can hand it your &[String] without conversion, or you can hand it a >> &[&str], and it will work with both. >> >> This doesn't necessarily mean you need to use <S: Str> &[S] everywhere. >> But it's a nice thing to do if you think about it. >> >> -Kevin >> > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
