ShallowCopy for byte::Bytes about left-right

[jonhoo]

Hmm.. I think it should be okay do have:

impl ShallowCopy for Bytes {
    unsafe fn shallow_copy(&mut self) -> Self {
        Bytes::from_static(self.as_ref())
    }
}

Along those lines, I also think it would be good to add

impl<'a, T> ShallowCopy for &'a [T] {
    unsafe fn shallow_copy(&mut self) -> Self {
        std::slice::from_raw_parts(self.as_ptr(), self.len())
    }
}

I'd be happy to take a look at a PR that adds these :)

[PlaneB]

You want to look into a program that uses those trait implementations? I will try them eventually. What minimal code do you need and why you want to see it?

[jonhoo]

I'm not sure I understand what you mean? Those trait implementations would need to be added to evmap itself for you to be able to rely on them in an external crate.

[PlaneB]

A really? Ok I was under the impression, that the user software implement those traits for Bytes in their code. Because you can not implement ShallowCopy for all types in evmap. Its the users duty to implement it on the types they use. Not?

[jonhoo]

Ah, no, we're limited here by Rust's orphan rule:

One restriction to note with trait implementations is that we can implement a
trait on a type only if either the trait or the type is local to our crate.
For example, we can implement standard library traits like Display on a
custom type like Tweet as part of our aggregator crate functionality,
because the type Tweet is local to our aggregator crate. We can also
implement Summary on Vec<T> in our aggregator crate, because the trait
Summary is local to our aggregator crate.

But we can’t implement external traits on external types. For example, we
can’t implement the Display trait on Vec<T> within our aggregator crate,
because Display and Vec<T> are defined in the standard library and aren’t
local to our aggregator crate. This restriction is part of a property of
programs called coherence, and more specifically the orphan rule, so
named because the parent type is not present. This rule ensures that other
people’s code can’t break your code and vice versa. Without the rule, two
crates could implement the same trait for the same type, and Rust wouldn’t
know which implementation to use.

In other words, since evmap defines the ShallowCopy trait, either the byte crate would have to implement ShallowCopy for Bytes (which seems unlikely) or that implementation has to exist inside of evmap. Since byte::Bytes is so common, I think I'd be okay with including that impl directly here :)

[PlaneB]

I see. So I guess I have to wait for your update of evmap then, or use some other type until then.

[jonhoo]

Or you can submit a pull request yourself that makes the necessary changes (adding a dependency on byte, the impls above, and tests with the corresponding types) which I could then review and merge :)

[jonhoo]

Fixed in #30!