Skip to content
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

Pass by T or &T for small structs implementing Copy? #1

Open
jbuckmccready opened this issue Mar 3, 2021 · 0 comments
Open

Pass by T or &T for small structs implementing Copy? #1

jbuckmccready opened this issue Mar 3, 2021 · 0 comments
Labels
design decision Issue involves a larger library design decision

Comments

@jbuckmccready
Copy link
Owner

jbuckmccready commented Mar 3, 2021

For small structures that implement Copy such as Vector2 and PlineVertex, functions should be consistent in passing them by T (value) or by &T (reference), which do we choose? Currently they are always passed by value T. Compiled code is likely to be the same with fields being loaded into registers - question is mostly from an ergonomics/consistency consideration.

Advantages of pass by value:

  • Ownership is passed so it is easy to mutably update fields without having to first clone (never bump into ownership issues in general)
  • The structs implement the Copy trait so no calls to clone are required on the calling side
  • Avoid having to dereference using * in many cases where the owned value is required in some context (although may end up having to dereference on the calling side if starting with a reference...)

Disadvantage of pass by value:

  • Inconsistent with generic functions in the std library where everything is pass by reference by default
  • Have to use & to get reference to values often times for generic functions expecting a &T not a T
  • If more exotic larger numeric types are used it may be cheaper to pass by reference (considering the structs implement the Copy trait this may the least of our worries in attempting to support such a scenario...)
@jbuckmccready jbuckmccready added the design decision Issue involves a larger library design decision label Mar 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design decision Issue involves a larger library design decision
Projects
None yet
Development

No branches or pull requests

1 participant