-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modify interface to take parameters as reference #31
Comments
@hug-dev would this impact the SE driver in a major way? |
what do you think would be the advantages of this? Do you have any examples in mind?
I don't think so! It can adapt 😃 |
Yeah, the key name is a big example - we take it as an owned string everywhere... it would be much nicer and idiomatic for a user to just do |
Definitely agree for the name! For the other non-Copy type, I guess we will have to review them on a case-by-case basis. Basically it only depends if the client needs to re-use the values after calling the function. |
I guess the default should be to take references everywhere unless the types are |
I think we've debated this before - passing by reference ends up "hiding" the fact that you actually want an instance of that data and that you're going to clone it. I don't know if it's sensible to just assume that if a type implements |
I think most
|
Most parameters get owned by the client once a method call is performed - this could/should be changed so that most parameters are instead passed by reference. The client can clone whatever it needs inside the methods.
The question is whether data buffers that we would normally own and zeroize on drop should be passed as references too.
The text was updated successfully, but these errors were encountered: