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
Is your feature request related to a problem? Please describe.
I wondered about the Send trait bounds required when binding arguments to, say, a Query, because it is the only thing preventing things like an Encode impl for std::fmt::Arguments.
While there's the Text adapter, it relies on a Display impl, so you need a dedicated type with a given Display impl to encode a message. std::fmt::Arguments is more dynamic, but it is not Send.
Describe the solution you'd like
I experimented with removing Send from the various bind() like methods and things seem to still work. The arguments buffer still is and probably needs to be Send, but arguments passed in bind() calls and encoded away don't really seem to need to be thread-safe, as the encoding is a sync operation.
Text could then in fact even rely on the Encode impl of std::fmt::Arguments.
Describe alternatives you've considered
Leave things as they are. It's not a big deal, but just a bit more performance and flexibility in encoding formatted messages without allocations.
Additional context
N/A.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I wondered about the
Send
trait bounds required when binding arguments to, say, aQuery
, because it is the only thing preventing things like anEncode
impl forstd::fmt::Arguments
.While there's the
Text
adapter, it relies on aDisplay
impl, so you need a dedicated type with a givenDisplay
impl to encode a message.std::fmt::Arguments
is more dynamic, but it is notSend
.Describe the solution you'd like
I experimented with removing
Send
from the variousbind()
like methods and things seem to still work. The arguments buffer still is and probably needs to beSend
, but arguments passed inbind()
calls and encoded away don't really seem to need to be thread-safe, as the encoding is a sync operation.Text
could then in fact even rely on theEncode
impl ofstd::fmt::Arguments
.Describe alternatives you've considered
Leave things as they are. It's not a big deal, but just a bit more performance and flexibility in encoding formatted messages without allocations.
Additional context
N/A.
The text was updated successfully, but these errors were encountered: