Since zeros are a valid value for any ByteValued type, we can use that instead of relying on a Default implementation (which may not be auto-derivable for some array types).
Further optimizations would be possible if we would have access to a pointer value into the source data. Then we could also use ptr::copy_nonoverlapping and avoid pre-initialization altogether. But changing the API just for that seems a bit excessive.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
[x] All commits in this PR are signed (with git commit -s), and the commit
message has max 60 characters for the summary and max 75 characters for each
description line.
[x] All added/changed functionality has a corresponding unit/integration
test.
[x] All added/changed public-facing functionality has entries in the "Upcoming
Release" section of CHANGELOG.md (if no such section exists, please create one).
[x] Any newly added unsafe code is properly documented.
Since zeros are a valid value for any ByteValued type, we can use that instead of relying on a Default implementation (which may not be auto-derivable for some array types).
Further optimizations would be possible if we would have access to a pointer value into the source data. Then we could also use ptr::copy_nonoverlapping and avoid pre-initialization altogether. But changing the API just for that seems a bit excessive.
Requirements
Before submitting your PR, please make sure you addressed the following requirements:
git commit -s), and the commit message has max 60 characters for the summary and max 75 characters for each description line.unsafecode is properly documented.