-
Notifications
You must be signed in to change notification settings - Fork 2
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
Allow slice concatenation without initial value. #4
Conversation
It seems it fails due to the unused variable when using the old syntax. ([$init:expr; $T:ty]: $($s:expr),* $(,)?) => {{
{let _ = $init;};
$crate::_concat_slices!([$T]: $($s),*)
}}; We could either add an underscore to the test variable, and let clippy warn the users that they can remove the initializer, or completely silence it by changing the macro branch as shown above. Just did some tests in my application that uses constcat. Resulting binary doesn't change either way, as the release binary was exactly the same (used diff, and cmp for comparisons). I'm personally on the side of warning the users. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! I suspected there might be some way to not have to specify the initializer but I didn't think of this, so thanks :)
Co-authored-by: Ross MacArthur <[email protected]>
Co-authored-by: Ross MacArthur <[email protected]>
Everything is ready now. I decided to also add a few more test cases just in case. |
This is done by making use of
core::mem::MaybeUninit
and then transmuting the array, once all of the values are initialized.The older syntax was left in for backwards compatibility purposes.
There is only a single line of unsafe code added as it was required for the change.
The safety of the unsafe block has been explained right above as a comment, its related documentation has been linked.
The related sections in documentation has been updated, and a testing case was added for the change that was made.
That being said, since the PR does introduce unsafe code, and it might not be desired to introduce unsafe code in the library, which I completely understand.