<div dir="ltr"><div dir="ltr">Am Mi., 5. Jan. 2022 um 13:11 Uhr schrieb Harendra Kumar <<a href="mailto:harendra.kumar@gmail.com">harendra.kumar@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...] In my opinion, the right thing here is to have uniform<br>
semantics with a non-zero size for objects that are stored or<br>
retrieved from memory.</blockquote><div><br></div><div>Which way is more uniform seems to depend on your POV, and base's choice has been made a long time ago, so that ship has sailed...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> If I were the owner of the base package I would do that.</blockquote><div><br></div><div>Then I'm quite happy that you aren't. ;-) API breakages should have a *very* good reason, not just that it makes life easier for a single library.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> This optimization in my opinion is a micro-optimization which<br>
is irrelevant in the larger scheme of things. If someone wants to<br>
optimise for this case there could be ways to do that. But again it is<br>
subjective - this vs that.<br></blockquote><div><br></div><div>IIRC there were no deep thoughts or arguments about optimizations at all at that time, but I still find the Storable () instance OK in its current state today.</div></div></div>