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
