-
-
Notifications
You must be signed in to change notification settings - Fork 480
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.mdentrySummary
Fillimpls to types safely reinterpretable as a byte-slice. This removes additional capability gained in Replace AsByteSliceMut with Fill #940.Fillto the element type, not slice/array. This supports external impls on externally-defined types. Fixes CHANGE: AllowFillto be implemented for third-party types #1650.rand_corecrate, rename, move RNG generic parameter to traitmin_specializationfor 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_coreand 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_slicetoRngCore. Adding these methods would be more disruptive, but possibly more useful overall (dyntrait support, no dependence on unstable features).Forget these specializations
... there's no strong evidence we need them.