Skip to content
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

Remove weak_rng #3

Closed
wants to merge 1 commit into from
Closed

Conversation

nagisa
Copy link
Contributor

@nagisa nagisa commented Feb 3, 2015

Documentation for the function claims it will return the fastest algorithm
available in Rust, but since its return type is hardcoded to XorShiftRng, it
would be an impossible [breaking-change], when, or if, a faster Rng is added to
Rust.

[breaking-change], since this removes public API. Uses of weak_rng function
can be replaced with random::<XorShiftRng>() to achieve almost the same
behaviour.

This is rust-lang/rust#20773.

Documentation for the function claims it will return the fastest algorithm
available in Rust, but since its return type is hardcoded to XorShiftRng, it
would be an impossible [breaking-change], when, or if, a faster Rng is added to
Rust.

[breaking-change], since this removes public API. Uses of `weak_rng` function
can be replaced with `random::<XorShiftRng>()` to achieve almost the same
behaviour.
@nagisa nagisa mentioned this pull request Feb 3, 2015
@alexcrichton
Copy link
Contributor

r? @huonw

@huonw
Copy link
Contributor

huonw commented Feb 8, 2015

I've merged this into the next branch, https://github.com/rust-lang/rand/tree/next. I want to keep master "clean" as a drop-in replacement for std::rand, including whatever minor updates are necessary to track nightly. Once we've collected enough improvements, I'm intending to merge that into master and release 0.2 (or 0.3 or whatever), possibly maintaining a legacy branch for the drop-in 0.1.x releases for a little while or just dropping it entirely (depending how soon the switch happens).

@huonw huonw closed this Feb 8, 2015
@huonw
Copy link
Contributor

huonw commented Feb 8, 2015

Thanks!

vks pushed a commit to vks/rand that referenced this pull request Apr 9, 2018
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.

A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.

For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.

This breaks code like:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

Change this code to:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    impl Copy for Point2D {}

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

This is the backwards-incompatible part of #13231.

Part of RFC rust-random#3.

[breaking-change]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants