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
I'm using the remote attribute in my derive proc macro within serde_many, and I've encountered an issue with constraining the implementation bounds added by the Serialize derive macro.
The core issue is that I cannot call Point::serialize because it is subject to bounds generated by the Serialize derive macro. Normally, one would rely on the Point: Serialize constraint, but the use of the remote attribute prevents this.
I suggest introducing a new trait, RemoteSerialize, which would be defined as:
With this approach, the remote attribute will implement the RemoteSerialize trait, and one could use constrain his implementation with the bounds of the trait implmentation (Point: RemoteSerialize<__Derived>). Of course a similar change would be made for RemoteDeserialize.
What do you think about this change?
Would you accept a PR for this?
Thanks!
The text was updated successfully, but these errors were encountered:
I'm using the
remote
attribute in my derive proc macro within serde_many, and I've encountered an issue with constraining the implementation bounds added by theSerialize
derive macro.This is how my derive proc macro works:
expands to:
The core issue is that I cannot call
Point::serialize
because it is subject to bounds generated by theSerialize
derive macro. Normally, one would rely on thePoint: Serialize
constraint, but the use of theremote
attribute prevents this.I suggest introducing a new trait,
RemoteSerialize
, which would be defined as:With this approach, the
remote
attribute will implement theRemoteSerialize
trait, and one could use constrain his implementation with the bounds of the trait implmentation (Point: RemoteSerialize<__Derived>
). Of course a similar change would be made forRemoteDeserialize
.What do you think about this change?
Would you accept a PR for this?
Thanks!
The text was updated successfully, but these errors were encountered: