You don't. Or less snarky, I imagine you'd have to use macros to generate wrapper functions, in order to generate a new function of a user provided type.
Agreed, and just to make it shorter and clearer; when you resume a debugger, it resumes at that next address. If it's outside a basic block, it's because in the absence of a debug break, it was about to go off the rails anyway, nothing to do with the break.
The strings are equally likely if they're being purely randomly selected, but not if they're being selected by people with a poor understanding of random. In the latter case, people are more likely to select HTHTHT.
I wonder what thought process led you to believe that even though the strings are equally likely and random, people who don't choose the one you think is more random have somehow inferior understanding of randomness
The issue the anecdote is reflecting is that across the data of 50 naive made-up coin tosses there are too many alternating sequences and probably zero HHHHHH.
I understand your point, but the context is that repeatedly, experiments have shown that humans inject too much pattern to be good rngs. It turns out that is visible with training after the fact.
Yes, it is possible that any two 50-sequence patterns are actual rng. But some of them are much more likely, and we can tell.
I'm not sure what your point is. A collection of samples were taken from humans, and they did not form a uniform distribution. Samples from an unbiased RNG are much closer to uniform.
Are you saying we should ignore the distribution we observe from humans and predict them as uniform anyway?
You say yourself "strings are equally likely if they're being purely randomly selected". So you move the goalpost to define "random" as "whatever a human would think is random".
> Samples from an unbiased RNG
you mean a PRNG.
> Are you saying we should ignore the distribution we observe from humans and predict them as uniform anyway?
I'm saying the exercise in general is a little pointless, but that's fine.
You're claiming that this bug that reproduces back to Rust 1.4 (2015) is a sign they're adding too many features to make sure they don't introduce bugs? Or do you have bugs that are due to these recent features?
On further reading, the Drop impl is a red herring. The bug is unrelated to Drop. It's there in the repro to show the effects of invalid assignment, but even without impl Drop the bug is still there.
The bug in the OP is about UNconditional impl. And honestly, looks like very standard code, definitely something that could've been written for real. I can't even explain why it passes checks, it clearly shouldn't.
impl Drop for Q {
fn drop(&mut self) { if let Some(t) = self.0.take() { KEPT.lock().unwrap().push(Box::new(t)); } }
}
The bound on T in the Drop impl means Drop is not implemented for all T, only where T: 'static + Send. Q also having the same bound doesn't make a difference to the Drop impl.
struct Q(Option);
impl Drop for Q {
fn drop(&mut self) {}
}
error[E0367]: `Drop` impl requires `T: 'static` but the struct it is implemented for does not
--> src/main.rs:3:9
|
3 | impl Drop for Q {
| ^^^^^^^
|
note: the implementor must specify the same requirement
--> src/main.rs:1:1
|
1 | struct Q(Option);
| ^^^^^^^^^^^
Even if the bounds are the same on the struct and the impl, it's still true that placing bounds on the Drop impl means it's not implemented for all T (just all T that also satisfy Q).
You also don't have to place those bounds on the Drop impl just because they're on Q, that's not an error.
The Drop isn't implemented for T at all. It's only implemented for Q. And it's implemented for all Q, in the sense that for every value of type Q, this Drop impl applies.
And I'm still not any closer to understanding what the bug is about.
Sorry, yes. I mean that Drop isn't implemented for all Q, just all Q where T meet the bounds of legally constructing Q. I note the difference because you can write a Drop impl with no bounds on T, and I believe it would not be able to trigger the bug.
This is so stupid. One, why did they make Drop special in this one way when every other trait impl has to repeat all bounds exactly to be valid? Two, the bug isn't even in the Drop impl, it's in the assignment on line 11. q.0 can never be Some(&l) because &l is not 'static. The Drop impl is there just to show the invalid read, but the bug doesn't require it, it's just as wrong for types that don't impl Drop.
They didn't special case this (in this way at least). You only need to specify the bounds relevant to this impl at this point.
It doesn't even have to be less constrained than the containing types definition. You can provide an impl with more constraints; for example, a type Q, but impl Seek for Q
I thought only as constrained and more constrained is allowed, and less constrained is always an error. At least that's been my experience - if `Q`, then I could never get `impl Q` working in any conditions until I added `where T: A`.
Do you happen to know the specific rules of when it's an error and when it's not?
It looks like you're right, my memory is wrong re. trait bounds. My guess then is that it only works for lifetimes because they involve subtyping, and impl Drop for all T means that it's valid for more constrained lifetimes.
I have terrible news about the distribution of iPhones and the middle class globally.
reply