Open birkenfeld opened 7 years ago
Sounds like a good idea; my hunch is that we should aim to wrap APIs even if they only differ in performance characteristics from functionality already wrapped.
Now that we are making send()
more generic, we should aim to subsume zmq_send_const()
under send()
as well. Probably that would work out by adding a Sendable
trait, and moving the current send()
code to impl<T> Sendable for T where T: Into<Message> { ... }
.
Now that I've sketched that approach, it doesn't work out as intended, as that would need trait specialization (RFC 1210, tracked here) to allow the compiler to chose the &'static [u8]
implementation over the one for &[u8]
using Into<Message>
.
Assuming we can wait for RFC being implemented before dealing with this issue, we should be able to provide the fix to this issue as a backwards-compatible optimization once we changed send()
to require Sendable
instead of Into<Message>
.
ZMQ 4.2 has an API called zmq_send_const, which allows sending static data without having to be copied into a Message.
Do we want to support this special case (for
&'static [u8]
arguments)?