You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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?
The text was updated successfully, but these errors were encountered: