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

Add impl for Clone trait for FontVec #111

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

GNUqb114514
Copy link

This implements Clone trait for FontVec.

It is just a small change,
but it can co-operate with a lot of Rust's generic mechanism (e.g. impl<T, A> Clone for Vec<T, A>),
and are good for convienience (e.g. now we can vec_of_fontvecs.clone()).

It justs called 2 exist method.
@alexheretic
Copy link
Owner

Cloning font data is quite inefficient though as fonts are often fairly large, if you need to clone it is much better to use a FontArc. The proposed mechanism is also doable externally already. It is possible that not having Clone for FontVec is generally preferable to steer users in a better performing direction.

Can you help me understand the use case?

@@ -104,6 +104,12 @@ impl fmt::Debug for FontVec {
}
}

impl Clone for FontVec {
fn clone(&self) -> Self {
Self::try_from_vec(self.as_slice().to_vec()).unwrap()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this impl means that mutations, e.g. setting variations, will not be present in the "cloned" output which would be incorrect.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I have no better ideas. Maybe byte-to-byte clone?

@GNUqb114514
Copy link
Author

Cloning font data is quite inefficient though as fonts are often fairly large, if you need to clone it is much better to use a FontArc. The proposed mechanism is also doable externally already. It is possible that not having Clone for FontVec is generally preferable to steer users in a better performing direction.

Well, you're probably right.

Can you help me understand the use case?

Well, someone may using an old computer that have no Arc support.

Note: This type is only available on platforms that support atomic loads and stores of pointers, which includes all platforms that support the std crate but not all those which only support alloc. This may be detected at compile time using #[cfg(target_has_atomic = "ptr")]. -- The Rust Standard Library Document, std::sync::Arc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants