Implement SourceCode for Vec<u8>

[Phantomical]

SourceCode is implemented for &str, String, and &[u8] but it is missing an impl for Vec<u8>.

[Benjamin-L]

Thoughts on just replacing the existing impls with the following?

impl SourceCode for [u8] { ... }
impl SourceCode for str { ... }
impl<T: Deref + Send + Sync> SourceCode for T  where T::Target: SourceCode { ... }

This should cover all the existing impls, Vec<u8>, and any other smart pointer types, including ones outside of std.

[zkat]

wait really?

If that won't be a breaking change, that does seem better!

[Benjamin-L]

It's technically a breaking change, because it may overlap with existing downstream impls. For example, suppose the following code was in some dependent crate:

struct Foo(String);

impl Deref for Foo {
    type Target = str;
    ...
}

impl SourceCode for Foo { ... }

That SourceCode impl is now invalid, because it conflicts with the blanket impl we're adding, breaking the trait coherence rules.

RFC 1105 states that implementing traits is only considered minor though, even though it is always technically breaking. However, the type of breaking change discussed there has to do with dispatch ambiguity rather than coherence, so I'm not sure the same reasoning applies. Fixing dispatch ambiguity issues is very straightforward, while fixing this type of coherence issue might require much deeper changes.

I'm not sure how much of an issue this is in practice. I wish there was an easy way to just build all the dependent crates against a proposed change like this, similar to how crater works for rustc changes :)

[Phantomical]

Would it be alright to merge this PR by itself and then have a second one with the breaking impl based on Deref? The changes here right now are not breaking changes and it would be nice to have the impl for Vec<u8> available.

[Benjamin-L]

Yeah, when I originally suggested the Deref option I hadn't thought through the fact that it's potentially breaking.

[zkat]

Let's merge this in for now, then :)