make Block cheaply cloneable

[rkuhn]

trafficstars

Since Block appears in APIs over multiple crates (mostly as &Block) and it doesn’t offer mutation methods, it would be reasonable to assume that an implementation of a consumer should want to hold on to the bytes it got — which today requires making a copy. The only adversely affected method would be Block::into_inner(), which probably would become less useful by such a change, as moving between Arc and Vec always requires an allocation.

What do you think?

[vmx]

To be honest, I haven't spend much time thinking about the Block interface, even when it was created. I'm still busy with the lower level things. I've no idea when I'll find to think this fully through. Hence I'd leave it to your judgement if it makes sense.

[MarcoPolo]

What's the use case you're looking to support? Is it that a consumer gets a &Block and wants their own Block without having to deal with lifetimes?

[rkuhn]

Yes, @MarcoPolo, that was what triggered my question. If we concede that cloning is expensive and that consumers may want to own them, then some traits should be changed to take Block instead of &Block — my estimate was that making Block cheaply cloneable would avoid the associated source code churn.