-
-
Notifications
You must be signed in to change notification settings - Fork 473
Let Fill target element types; move to rand_core; support min_specialization #1651
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
Conversation
These impls contradict the doc that fn fill is implemented for types which may be reinterpreted as [u8].
Note: it might seem more natural to reverse the generics and parameters of pub trait Fill<T> {
fn fill_slice(&mut self, slice: &mut [T]);
} Indeed, it is more natural. Unfortunately it does not support external impls for externally-defined types like |
Wouldn't it be better to rely on |
8867221
to
c13c5a2
Compare
Aside from #1574, that wouldn't support RNG specializations. It also would require unsafe code to implement for user-defined types (though some impls will require that anyway). |
What do you not like about moving |
I don't think RNG specialization is that important. The only difference between filling
No, if user has successfully derived
This feels like a wrong place for it. It goes against the goal of providing the fundamental RNG APIs. |
I agree except that I've been reconsidering what the fundamental RNG APIs should be. This is sort-of a part of that. The "sort-of" part is where this proposal falls flat though IMO since Do you think this |
I haven't used |
#1652 was merged instead. |
CHANGELOG.md
entrySummary
Fill
impls to types safely reinterpretable as a byte-slice. This removes additional capability gained in Replace AsByteSliceMut with Fill #940.Fill
to the element type, not slice/array. This supports external impls on externally-defined types. Fixes CHANGE: AllowFill
to be implemented for third-party types #1650.rand_core
crate, rename, move RNG generic parameter to traitmin_specialization
for RNGsMotivation
This trait was added to fill a capability gap: a safe interface for fast filling of slices like
[i16]
. The impls for[bool]
,[f32]
etc. are extra complexity beyond this and unnecessary since they offer no benefit over element-wise generation in user-code.Further, we can now support specialization like this:
Alternatives
The specialization option motivated removal of support for element-wise types (
[f32]
etc.), moving torand_core
and moving the generics to the trait. I don't think any of these are bad changes however.Via RngCore
We could add
fill_u32_slice
,fill_u64_slice
toRngCore
. Adding these methods would be more disruptive, but possibly more useful overall (dyn
trait support, no dependence on unstable features).Forget these specializations
... there's no strong evidence we need them.