Implement AsRef and AsMut for str, [T] and some other unsized types

[mexus]

As discussed in #28

I've also made tests to make sure that we are getting what we really want to. On the other hand the functionality and implementation is so simple and straightforward, while the tests are a little bit clumsy (especially for AsMut<str>), so I'm hesitating on whether or not we should keep them.

[mexus]

Hi @cuviper ! Could you pls have a look at the PR?
I'm not really sure whom to invite to make a review (apart from you), maybe you have an idea whom else to ping?
Thanks!

[cuviper]

I see what you mean about AsMut<str> being clumsy. Maybe we should take a cue from those unsized types that are explicitly implemented in the standard library:

• AsRef<str>
• AsRef<CStr>
• AsRef<OsStr>
• AsRef<Path>
• AsRef<[T]>
• AsMut<[T]>

So a few more candidates for AsRef, but none of those string-like types implement AsMut!

[cuviper]

Oh, now I see you already improved the "clumsy" tests. I was thinking about the problem since you posted the PR, but hadn't checked to see that you updated it. That definitely looks nicer.

Now I guess it's just a question of what unsized types we really want.

@bluss, any opinions? In case you missed it, in #28 we found that going fully ?Sized would technically be a breaking change -- though it would probably not affect anyone in practice...

[mexus]

Omg, I've completely forgotten about other unsized types! xD
Do you think I should put implementations for them either?.. If yes, then I'd rather let people who need it for some specific standard types to make pull requests than to introduce another ton of copy-paste code into the library, taking into consideration that everything can be easily implemented with just a single question mark... and a breaking release :)

[cuviper]

Macros can ease the copy-paste aspect of this, at least.

[mexus]

Added a couple of macros and implemented the traits in question for str, Path, OsStr and CStr

[bluss]

I'd love to do the ?Sized change, that's an oversight, but it's hard to see if it's possible to do. Generic is better than specific here.

Only PR comment is to update it so that it compiles with --no-default-features. Also an oversight that travis doesn't test that.

[mexus]

Will do later today, thanks for the hint!

[mexus]

Done!

Btw is it ok that I'm overwriting the same commit again and again? I can split the commits using my reflog if anybody finds it useful..

[mexus]

Just as a side question, why to maintain compatibility with rust-1.12?...

[cuviper]

It's an open question in the Rust community. Some consider it fine to only support the latest-stable rustc, and some think increasing the rustc requirement should be a breaking change. This crate has chosen the more conservative position to maintain compatibility.

[mexus]

... yet another point to roll out 2.0 :))
(just kidding)

So, it there anything else to amend in the PR?

[mexus]

Hi @cuviper, @bluss
Do you think I can improve the patch somehow so it gets merged? :)

[cuviper]

Sorry for neglecting this. I've just merged and published it as either 1.5.1.

[mexus]

No problem, there was no hurry or anything :) Thanks!