> 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? On Mon, May 26, 2014 at 5:55 PM, Kevin Ballard <ke...@sb.org> wrote: > captures() should not take <S: Str>. That's unnecessary, it should just > take &str as it does now. 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()). > > For the time being, the answer is to use .as_slice() explicitly. The > proposed Deref implementation post-DST has been talked about, and seems > reasonably likely (though no decision has been made about it). > > The remaining bit to this is that, AFAIK, we don't auto-deref function > arguments. We had auto-borrow of ~str into &str, but that doesn't apply to > String. It has been suggested that maybe we should auto-deref+autoref > function arguments such that String could then automatically coerce into > &str, but this has had very little discussion so far. > > My suggestion is to wait until we have DST, then file an RFC suggesting > the autoderef behavior for function arguments (and suggesting Deref on > String if we haven't already done that). > > -Kevin > > On May 26, 2014, at 12:10 PM, Benjamin Striegel <ben.strie...@gmail.com> > wrote: > > I don't think any of these will be necessary. > > We already have a trait called `Str` (which is a bad name, btw) in the > std::str module. This trait has exactly one method: `as_slice`. This trait > is already implemented on both `&str` and `StrBuf` (the former in std::str, > the latter in std::strbuf). All that would need to be done is to make the > `captures` method generic on any type that implements `Str`, and then have > it call the `as_slice` method before doing exactly what it does today. This > extra operation would compile to a no-op for slices, and the usual cheap > slice operation for heap-allocated strings. Then you would be able to call > `re.captures(foo)` regardless of whether `foo` was a `&str` or a `StrBuf`. > > > On Mon, May 26, 2014 at 3:46 AM, Igor Bukanov <i...@mir2.org> wrote: > >> Perhaps Rust should provide something like BorrowAsStr trait allowing >> to convert automatically to &str. &* is just too ugly... >> >> On 26 May 2014 08:58, Vladimir Matveev <dpx.infin...@gmail.com> wrote: >> >> My suspicion is that the automatic conversion will come back at some >> >> point, but I'm not sure. >> > >> > I think it will be possible to make `String` implement `Deref<str>` >> > when DST land. Then it will be possible to convert from `String` to >> > `&str` using explicit reborrowing: >> > >> > let sgf_slice = &*sgf; >> > >> > I'm not sure this will be fully automatic when `String` is an >> > arbitrary actual argument to arbitrary function, however. >> > >> > 2014-05-26 10:36 GMT+04:00 Andrew Gallant <jams...@gmail.com>: >> >> Try using `self.sgf.as_slice()` instead. >> >> >> >> The change is necessary, AFAIK, because `~str` would automatically be >> >> converted to a borrowed reference without having to explicitly call the >> >> `as_slice` method. This doesn't happen for the StrBuf (and what is now >> >> String, I think) type. >> >> >> >> My suspicion is that the automatic conversion will come back at some >> >> point, but I'm not sure. >> >> >> >> - Andrew >> >> >> >> >> >> On Mon, May 26, 2014 at 2:32 AM, Urban Hafner <cont...@urbanhafner.com> >> wrote: >> >>> Hello there, >> >>> >> >>> I just updated the compiler (I use the git master branch) and now >> when I >> >>> read in a file I get a StrBuf instead of a ~str. That is easy enough >> to >> >>> change, but how do I use regular expressions now? I have the >> following in my >> >>> code: >> >>> >> >>> let re = regex!(r"SZ\[(\d+)\]"); >> >>> let captures = re.captures(self.sgf).unwrap(); >> >>> >> >>> And it fails now because "self.sgf" is a StrBuf instead of a &str. Do >> I have >> >>> just a Rust compiler that is somewhere in between (i.e. not >> everything has >> >>> been changed to StrBuf) or is this intentional? And if so, what's the >> best >> >>> way to use regular expressions now? >> >>> >> >>> Urban >> >>> -- >> >>> Freelancer >> >>> >> >>> Available for hire for Ruby, Ruby on Rails, and JavaScript projects >> >>> >> >>> More at http://urbanhafner.com >> >>> >> >>> _______________________________________________ >> >>> Rust-dev mailing list >> >>> Rust-dev@mozilla.org >> >>> https://mail.mozilla.org/listinfo/rust-dev >> >>> >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev@mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev@mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
