tisonkun opened a new issue, #328: URL: https://github.com/apache/datasketches-rust/issues/328
For the next breaking release, consider removing these public methods: - `ReqSketch::serialized_size_bytes()` returns the exact encoded size and is used internally by `serialize()`. It can remain private. - `CpcSketch::max_serialized_bytes(lg_k)` returns an empirical estimate, not a guaranteed upper bound or the size of a particular sketch. It has no production callers inside the crate; if we remove the public API, delete the unused implementation too. The other sketches generally keep sizing inside serialization: KLL has a private size helper; Bloom, Count-Min, HLL, Frequencies, Theta, and Tuple calculate sizes internally. A size query is not uniformly cheap: CPC produces a compressed payload first, and mutable t-digest compresses its state during serialization. We should choose a consistent policy across sketches: 1. Keep size calculations internal. Callers needing the encoded bytes can use the resulting buffer's `len()`. 2. Provide a consistent public size-query API where callers need to check storage or message limits before allocating the output. Define exact size versus estimates, format variants, errors, and whether querying requires traversal, compression, or mutation. The first option keeps the API smaller; the second needs a concrete caller use case and may repeat work done by serialization. Avoid keeping unrelated public helpers solely because other implementations expose them. This concerns sketch-level size queries, not the per-value sizing methods required by item serialization traits. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
