Repository navigation
make Block cheaply cloneable #146
Description
Activity
To be honest, I haven't spend much time thinking about the
Blockinterface, 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.What's the use case you're looking to support? Is it that a consumer gets a
&Blockand wants their own Block without having to deal with lifetimes?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
Blockinstead of&Block— my estimate was that making Block cheaply cloneable would avoid the associated source code churn.
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 beBlock::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?