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

Add trim_start, trim_end etc.; deprecate trim_left, trim_right, etc. in future #52994

Merged
merged 4 commits into from Sep 6, 2018

Conversation

@varkor
Contributor

varkor commented Aug 2, 2018

Adds the methods: trim_start, trim_end, trim_start_matches and trim_end_matches.
Deprecates trim_left, trim_right, trim_left_matches and trim_right_matches starting from Rust 1.33.0, three versions from when they'll initially be marked as being deprecated, using the future deprecation from #30785 and #51681.

Fixes #30459.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Aug 2, 2018

Collaborator

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Aug 2, 2018

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@cramertj

This comment has been minimized.

Show comment
Hide comment
@cramertj

cramertj Aug 2, 2018

Member

Assigning someone on libs... r? @dtolnay

Member

cramertj commented Aug 2, 2018

Assigning someone on libs... r? @dtolnay

@rust-highfive rust-highfive assigned dtolnay and unassigned cramertj Aug 2, 2018

@rust-highfive

This comment was marked as resolved.

Show comment
Hide comment
@rust-highfive

rust-highfive Aug 2, 2018

Collaborator

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[01:03:10] ....................................................................................................
[01:03:17] ....................................................................................................
[01:03:24] ....................................................................................................
[01:03:33] ....................................................................................................
[01:03:41] ........................i.............FFF.F......F..FF.........................i....................
[01:03:42] failures:
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3642) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3642) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 6 | assert_eq!(" Hello\tworld", s.trim_end());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_end (line 3642)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3650) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3650) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert!(Some('h') == s.trim_end().chars().rev().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert!(Some('ת') == s.trim_end().chars().rev().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_end (line 3650)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3840) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3840) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 4 | assert_eq!("11foo1bar11".trim_end_matches('1'), "11foo1bar");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert_eq!("123foo1bar123".trim_end_matches(char::is_numeric), "123foo1bar");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert_eq!("12foo1bar12".trim_end_matches(x), "12foo1bar");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] thread 'str/mod.rs - str::str::trim_end_matches (line 3840)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3850) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3850) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 4 | assert_eq!("1fooX".trim_end_matches(|c| c == '1' || c == 'X'), "1foo");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] thread 'str/mod.rs - str::str::trim_end_matches (line 3850)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3606) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3606) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 6 | assert_eq!("Hello\tworld\t", s.trim_start());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_start (line 3606)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3614) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3614) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert!(Some('E') == s.trim_start().chars().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert!(Some('ע') == s.trim_start().chars().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_start (line 3614)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_start_matches (line 3801) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_start_matches (line 3801) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 4 | assert_eq!("11foo1bar11".trim_start_matches('1'), "foo1bar11");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert_eq!("123foo1bar123".trim_start_matches(char::is_numeric), "foo1bar123");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert_eq!("12foo1bar12".trim_start_matches(x), "foo1bar12");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_start_matches (line 3801)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] 
[01:03:42] failures:
---
[01:03:42] 
[01:03:42] error: test failed, to rerun pass '--doc'
[01:03:42] 
[01:03:42] 
[01:03:42] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "core" "--" "--quiet"
[01:03:42] 
[01:03:42] 
[01:03:42] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:03:42] Build completed unsuccessfully in 0:20:37
[01:03:42] Build completed unsuccessfully in 0:20:37
[01:03:42] make: *** [check] Error 1
[01:03:42] Makefile:58: recipe for target 'check' failed
60840 ./src/llvm-emscripten/lib
59588 ./obj/build/x86_64-unknown-linux-gnu/stage2-tools
55548 ./obj/build/x86_64-unknown-linux-gnu/stage0/bin
55268 ./obj/build/x86_64-unknown-linux-gnu/stage0-rustc

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

Collaborator

rust-highfive commented Aug 2, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[01:03:10] ....................................................................................................
[01:03:17] ....................................................................................................
[01:03:24] ....................................................................................................
[01:03:33] ....................................................................................................
[01:03:41] ........................i.............FFF.F......F..FF.........................i....................
[01:03:42] failures:
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3642) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3642) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 6 | assert_eq!(" Hello\tworld", s.trim_end());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_end (line 3642)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3650) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end (line 3650) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert!(Some('h') == s.trim_end().chars().rev().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert!(Some('ת') == s.trim_end().chars().rev().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_end (line 3650)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3840) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3840) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 4 | assert_eq!("11foo1bar11".trim_end_matches('1'), "11foo1bar");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert_eq!("123foo1bar123".trim_end_matches(char::is_numeric), "123foo1bar");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert_eq!("12foo1bar12".trim_end_matches(x), "12foo1bar");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] thread 'str/mod.rs - str::str::trim_end_matches (line 3840)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3850) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_end_matches (line 3850) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 4 | assert_eq!("1fooX".trim_end_matches(|c| c == '1' || c == 'X'), "1foo");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] thread 'str/mod.rs - str::str::trim_end_matches (line 3850)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3606) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3606) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 6 | assert_eq!("Hello\tworld\t", s.trim_start());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_start (line 3606)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3614) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_start (line 3614) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert!(Some('E') == s.trim_start().chars().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert!(Some('ע') == s.trim_start().chars().next());
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_start (line 3614)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] ---- str/mod.rs - str::str::trim_start_matches (line 3801) stdout ----
[01:03:42] ---- str/mod.rs - str::str::trim_start_matches (line 3801) stdout ----
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 4 | assert_eq!("11foo1bar11".trim_start_matches('1'), "foo1bar11");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 5 | assert_eq!("123foo1bar123".trim_start_matches(char::is_numeric), "foo1bar123");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] 
[01:03:42] error[E0658]: use of unstable library feature 'trim_direction' (see issue #30459)
[01:03:42]   |
[01:03:42]   |
[01:03:42] 8 | assert_eq!("12foo1bar12".trim_start_matches(x), "foo1bar12");
[01:03:42]   |
[01:03:42]   |
[01:03:42]   = help: add #![feature(trim_direction)] to the crate attributes to enable
[01:03:42] thread 'str/mod.rs - str::str::trim_start_matches (line 3801)' panicked at 'couldn't compile the test', librustdoc/test.rs:333:13
[01:03:42] 
[01:03:42] 
[01:03:42] failures:
---
[01:03:42] 
[01:03:42] error: test failed, to rerun pass '--doc'
[01:03:42] 
[01:03:42] 
[01:03:42] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "core" "--" "--quiet"
[01:03:42] 
[01:03:42] 
[01:03:42] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:03:42] Build completed unsuccessfully in 0:20:37
[01:03:42] Build completed unsuccessfully in 0:20:37
[01:03:42] make: *** [check] Error 1
[01:03:42] Makefile:58: recipe for target 'check' failed
60840 ./src/llvm-emscripten/lib
59588 ./obj/build/x86_64-unknown-linux-gnu/stage2-tools
55548 ./obj/build/x86_64-unknown-linux-gnu/stage0/bin
55268 ./obj/build/x86_64-unknown-linux-gnu/stage0-rustc

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@kennytm kennytm added the T-libs label Aug 3, 2018

Show outdated Hide outdated src/libcore/str/mod.rs
Show outdated Hide outdated src/libcore/str/mod.rs
@dtolnay

This comment was marked as resolved.

Show comment
Hide comment
@dtolnay

dtolnay Aug 5, 2018

Member

@rust-lang/libs this PR adds stable methods intended as direct replacements for the existing str::trim_left, trim_right, trim_left_matches, trim_right_matches.

impl str {
    pub fn trim_start(&self) -> &str;

    pub fn trim_end(&self) -> &str;

    pub fn trim_start_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>;

    pub fn trim_end_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>,
        P::Searcher: ReverseSearcher<'a>;
}

The signatures are the same but the new names better describe the behavior on right-to-left input text. The old names will display a deprecation notice in the documentation but are not set to warn until 1.33.0.

@rfbot fcp merge

Member

dtolnay commented Aug 5, 2018

@rust-lang/libs this PR adds stable methods intended as direct replacements for the existing str::trim_left, trim_right, trim_left_matches, trim_right_matches.

impl str {
    pub fn trim_start(&self) -> &str;

    pub fn trim_end(&self) -> &str;

    pub fn trim_start_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>;

    pub fn trim_end_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>,
        P::Searcher: ReverseSearcher<'a>;
}

The signatures are the same but the new names better describe the behavior on right-to-left input text. The old names will display a deprecation notice in the documentation but are not set to warn until 1.33.0.

@rfbot fcp merge

@kennytm

This comment was marked as resolved.

Show comment
Hide comment
@kennytm

kennytm Aug 6, 2018

Member

(@dtolnay you mentioned @rfbot not @rfcbot)

Member

kennytm commented Aug 6, 2018

(@dtolnay you mentioned @rfbot not @rfcbot)

@dtolnay

This comment has been minimized.

Show comment
Hide comment
@dtolnay

dtolnay Aug 6, 2018

Member

@rust-lang/libs this PR adds stable methods intended as direct replacements for the existing str::trim_left, trim_right, trim_left_matches, trim_right_matches.

impl str {
    pub fn trim_start(&self) -> &str;

    pub fn trim_end(&self) -> &str;

    pub fn trim_start_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>;

    pub fn trim_end_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>,
        P::Searcher: ReverseSearcher<'a>;
}

The signatures are the same but the new names better describe the behavior on right-to-left input text. The old names will display a deprecation notice in the documentation but are not set to warn until 1.33.0.

@rfcbot fcp merge

Member

dtolnay commented Aug 6, 2018

@rust-lang/libs this PR adds stable methods intended as direct replacements for the existing str::trim_left, trim_right, trim_left_matches, trim_right_matches.

impl str {
    pub fn trim_start(&self) -> &str;

    pub fn trim_end(&self) -> &str;

    pub fn trim_start_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>;

    pub fn trim_end_matches<'a, P>(&'a self, pat: P) -> &'a str
    where
        P: Pattern<'a>,
        P::Searcher: ReverseSearcher<'a>;
}

The signatures are the same but the new names better describe the behavior on right-to-left input text. The old names will display a deprecation notice in the documentation but are not set to warn until 1.33.0.

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Aug 6, 2018

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot commented Aug 6, 2018

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Aug 8, 2018

Contributor

@rfcbot concern deprecation-schedule

I'm a big +1 on adding the more accurately named methods, but I'm uncertain that deprecating the old methods in 1.33 is the best decision. I don't see any discussion on that choice on this or the issue it closes. I'm not against it, I just want to raise it for discussion and see if anyone has anything to say about it before this goes into FCP.

I've checked my box so once I resolve this concern the PR will go into FCP.

Contributor

withoutboats commented Aug 8, 2018

@rfcbot concern deprecation-schedule

I'm a big +1 on adding the more accurately named methods, but I'm uncertain that deprecating the old methods in 1.33 is the best decision. I don't see any discussion on that choice on this or the issue it closes. I'm not against it, I just want to raise it for discussion and see if anyone has anything to say about it before this goes into FCP.

I've checked my box so once I resolve this concern the PR will go into FCP.

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Aug 8, 2018

Member

@withoutboats I have a vague unstructured opinion that we're a bit too quick to deprecate things in general, and I would probably apply it here too. But it's honestly a pretty weak opinion, particularly if we do add the new methods anyway. Here's a trichotomy to make my view a little clearer:

  1. Do nothing. Keep current methods; don't add new methods.
  2. Add new methods. Keep current methods and don't deprecate them.
  3. Add new methods. Keep current methods and deprecate them.

On a small scale, I'd probably go with (3) (because clarifications like this are nice). On a larger scale, I'd probably go with (1) (because there's churn, and I think there is a lot more room to accept warts). Route (2) seems somewhat inconsistent with what we've done in the past. That is, I don't think we have a lot of "this thing is an exact alias to this other thing." So in that sense, if we definitely want these new methods, I'd probably just go ahead any deprecate the existing ones.

What thoughts did you have on this?

Member

BurntSushi commented Aug 8, 2018

@withoutboats I have a vague unstructured opinion that we're a bit too quick to deprecate things in general, and I would probably apply it here too. But it's honestly a pretty weak opinion, particularly if we do add the new methods anyway. Here's a trichotomy to make my view a little clearer:

  1. Do nothing. Keep current methods; don't add new methods.
  2. Add new methods. Keep current methods and don't deprecate them.
  3. Add new methods. Keep current methods and deprecate them.

On a small scale, I'd probably go with (3) (because clarifications like this are nice). On a larger scale, I'd probably go with (1) (because there's churn, and I think there is a lot more room to accept warts). Route (2) seems somewhat inconsistent with what we've done in the past. That is, I don't think we have a lot of "this thing is an exact alias to this other thing." So in that sense, if we definitely want these new methods, I'd probably just go ahead any deprecate the existing ones.

What thoughts did you have on this?

@varkor

This comment has been minimized.

Show comment
Hide comment
@varkor

varkor Aug 8, 2018

Contributor

I don't see any discussion on that choice on this or the issue it closes.

👍I picked "3 releases from now" fairly arbitrarily, as a period that seemed somewhat reasonable. I probably should have clarified that — the FCP seems like as good a time as any to discuss it, though!

Contributor

varkor commented Aug 8, 2018

I don't see any discussion on that choice on this or the issue it closes.

👍I picked "3 releases from now" fairly arbitrarily, as a period that seemed somewhat reasonable. I probably should have clarified that — the FCP seems like as good a time as any to discuss it, though!

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Aug 8, 2018

Contributor

What thoughts did you have on this?

I really don't know. I guess I feel like these methods are widely used, and so deprecating them will be disruptive. So I'd like some headway before we start issuing warnings. As we can see, @varkor's already done at least some of that by implementing future deprecations & targeting 1.33 for deprecation, but is that enough? I'm not sure.

Some vague questions/thoughts:

  • How will we communicate about this future deprecation prior to 1.33 to try to encourage people to switch over (at least for new code)?
  • How do the future deprecated methods appear in docs? Does it successfully encourage people to switch? (I already asked varkor this on a separate thread) EDIT: Screenshot in #49179
  • What other ways could we encourage people to switch before we start issuing warnings?

I also have no idea how to judge if 3 releases is the correct number.

Contributor

withoutboats commented Aug 8, 2018

What thoughts did you have on this?

I really don't know. I guess I feel like these methods are widely used, and so deprecating them will be disruptive. So I'd like some headway before we start issuing warnings. As we can see, @varkor's already done at least some of that by implementing future deprecations & targeting 1.33 for deprecation, but is that enough? I'm not sure.

Some vague questions/thoughts:

  • How will we communicate about this future deprecation prior to 1.33 to try to encourage people to switch over (at least for new code)?
  • How do the future deprecated methods appear in docs? Does it successfully encourage people to switch? (I already asked varkor this on a separate thread) EDIT: Screenshot in #49179
  • What other ways could we encourage people to switch before we start issuing warnings?

I also have no idea how to judge if 3 releases is the correct number.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Aug 8, 2018

Contributor

Considering that:

  • Keeping a code base warning-free is generally nice / desired.
  • The same code can often be compiled with a range of different Rust versions. For example a library supports the Stable channel, but when contributing to it I might use Nightly to take advantage of tooling (not language or libs) improvements.

I’ve generally argued for not emitting deprecation warnings in Nightly until the recommended replacement is available on stable. So that means a 2 release cycles delay. However that’s a minimum, increasing it to 3 doesn’t cost us much and makes things easier for projects that mostly track Stable but still pin to a specific version, leaving them some more time to upgrade. For example Firefox’s policy is to upgrade 2 weeks after a new Stable is released (modulo blocking bugs).

For projects that have a policy of keeping compat with a specific version older than Stable, they’ll likely not want to bump their requirement for a simple renaming like this and might use #[allow(deprecated)] instead. So I’d be fine with a longer delay before we start emitting warnings.

Does rustdoc show an API as deprecated even before we start emitting warnings based on since? If not I think it should.

Contributor

SimonSapin commented Aug 8, 2018

Considering that:

  • Keeping a code base warning-free is generally nice / desired.
  • The same code can often be compiled with a range of different Rust versions. For example a library supports the Stable channel, but when contributing to it I might use Nightly to take advantage of tooling (not language or libs) improvements.

I’ve generally argued for not emitting deprecation warnings in Nightly until the recommended replacement is available on stable. So that means a 2 release cycles delay. However that’s a minimum, increasing it to 3 doesn’t cost us much and makes things easier for projects that mostly track Stable but still pin to a specific version, leaving them some more time to upgrade. For example Firefox’s policy is to upgrade 2 weeks after a new Stable is released (modulo blocking bugs).

For projects that have a policy of keeping compat with a specific version older than Stable, they’ll likely not want to bump their requirement for a simple renaming like this and might use #[allow(deprecated)] instead. So I’d be fine with a longer delay before we start emitting warnings.

Does rustdoc show an API as deprecated even before we start emitting warnings based on since? If not I think it should.

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Aug 9, 2018

Contributor

Does rustdoc show an API as deprecated even before we start emitting warnings based on since? If not I think it should.

Yea, you can see a screenshot in #49179

Contributor

withoutboats commented Aug 9, 2018

Does rustdoc show an API as deprecated even before we start emitting warnings based on since? If not I think it should.

Yea, you can see a screenshot in #49179

@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Aug 20, 2018

Contributor

If we add a deprecation, what's the worst that can happen? I can only think of the two following issues:

  • #![deny(warnings)], in which case, users want their builds to break when Rust's deprecates something
  • users that need to support Rust versions that are X time old and therefore cannot use the newer feature

In both cases, the "fix" is one line away: #![allow(warning_name)] (or e.g. #![cfg_attr(rust_version_gt_1_33_0, allow(warning_name)]). Sure, some might want to actually update their code to not use deprecated features, but that's something that they can do whenever they want however they want, they don't have to change anything right away if they don't want to.

C++ deprecation policy is that there should be an alternative available for (widely-used) deprecated features. Three examples:

  • auto_ptr was deprecated when {shared,unique,weak}_ptr were introduced,
  • std::async is not depreciated because its replacement has been postponed two std releases in a row,
  • export template was not widely used and was deprecated without an alternative available.

This policy looks sensible to me, and under this policy, we are introducing the alternative, therefore, we can deprecate right away.

I don't see any way to actually reliably warn users that in N releases we are going to deprecate something beyond adding a warning for that, which doesn't solve any problems. Are there any alternatives here?

What other issues does adding a deprecation warning introduce? For whom? How easy are these to "fix"?

Contributor

gnzlbg commented Aug 20, 2018

If we add a deprecation, what's the worst that can happen? I can only think of the two following issues:

  • #![deny(warnings)], in which case, users want their builds to break when Rust's deprecates something
  • users that need to support Rust versions that are X time old and therefore cannot use the newer feature

In both cases, the "fix" is one line away: #![allow(warning_name)] (or e.g. #![cfg_attr(rust_version_gt_1_33_0, allow(warning_name)]). Sure, some might want to actually update their code to not use deprecated features, but that's something that they can do whenever they want however they want, they don't have to change anything right away if they don't want to.

C++ deprecation policy is that there should be an alternative available for (widely-used) deprecated features. Three examples:

  • auto_ptr was deprecated when {shared,unique,weak}_ptr were introduced,
  • std::async is not depreciated because its replacement has been postponed two std releases in a row,
  • export template was not widely used and was deprecated without an alternative available.

This policy looks sensible to me, and under this policy, we are introducing the alternative, therefore, we can deprecate right away.

I don't see any way to actually reliably warn users that in N releases we are going to deprecate something beyond adding a warning for that, which doesn't solve any problems. Are there any alternatives here?

What other issues does adding a deprecation warning introduce? For whom? How easy are these to "fix"?

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Aug 20, 2018

Member

What other issues does adding a deprecation warning introduce? For whom? How easy are these to "fix"?

I don't think churn is being factored in enough in conversations about deprecation. It has a real aggregate cost IMO, but it is exceedingly difficult to measure. Every time we deprecate something, we risk making documentation somewhere outdated and impose a re-learning budget on everyone that uses those APIs. For any one particular change, this cost is perhaps very small (perhaps imperceptibly so), but it's going to add up over time.

I don't know if @withoutboats's concerns are the same as mine though!

Member

BurntSushi commented Aug 20, 2018

What other issues does adding a deprecation warning introduce? For whom? How easy are these to "fix"?

I don't think churn is being factored in enough in conversations about deprecation. It has a real aggregate cost IMO, but it is exceedingly difficult to measure. Every time we deprecate something, we risk making documentation somewhere outdated and impose a re-learning budget on everyone that uses those APIs. For any one particular change, this cost is perhaps very small (perhaps imperceptibly so), but it's going to add up over time.

I don't know if @withoutboats's concerns are the same as mine though!

@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Aug 20, 2018

Contributor

I don't think churn is being factored in enough in conversations about deprecation. It has a real aggregate cost IMO, but it is exceedingly difficult to measure. Every time we deprecate something, we risk making documentation somewhere outdated and impose a re-learning budget on everyone that uses those APIs. For any one particular change, this cost is perhaps very small (perhaps imperceptibly so), but it's going to add up over time.

I agree with everything you said, but the impression that this conversation gave me is that there is currently no consensus about which grace period to give before performing the deprecation, but that there was already a consensus that, for this case, the deprecation was worth doing. Sorry if I misinterpreted the situation.

Contributor

gnzlbg commented Aug 20, 2018

I don't think churn is being factored in enough in conversations about deprecation. It has a real aggregate cost IMO, but it is exceedingly difficult to measure. Every time we deprecate something, we risk making documentation somewhere outdated and impose a re-learning budget on everyone that uses those APIs. For any one particular change, this cost is perhaps very small (perhaps imperceptibly so), but it's going to add up over time.

I agree with everything you said, but the impression that this conversation gave me is that there is currently no consensus about which grace period to give before performing the deprecation, but that there was already a consensus that, for this case, the deprecation was worth doing. Sorry if I misinterpreted the situation.

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Aug 20, 2018

Member

@gnzlbg Ah yes, good point!

Member

BurntSushi commented Aug 20, 2018

@gnzlbg Ah yes, good point!

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Aug 20, 2018

Contributor

I'm focused more on the moment of deprecation: it can be very annoying when you have deprecation warnings all over your projects. Ideally we could ease into this by giving as many people as possible advanced notice.

How can we communicate future deprecations? We could add an additional section to the release announcement? Is saying "We will be deprecating this in 1.33" three times enough notice? Should we tweet about it from the rustlang twitter?

There's no disagreement about deprecating these APIs, we just have to determine what our "widely used API deprecation" strategy is.

Contributor

withoutboats commented Aug 20, 2018

I'm focused more on the moment of deprecation: it can be very annoying when you have deprecation warnings all over your projects. Ideally we could ease into this by giving as many people as possible advanced notice.

How can we communicate future deprecations? We could add an additional section to the release announcement? Is saying "We will be deprecating this in 1.33" three times enough notice? Should we tweet about it from the rustlang twitter?

There's no disagreement about deprecating these APIs, we just have to determine what our "widely used API deprecation" strategy is.

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Aug 20, 2018

Contributor

also: can cargo fix fix these? not a blocker, but would be nice

Contributor

withoutboats commented Aug 20, 2018

also: can cargo fix fix these? not a blocker, but would be nice

@varkor

This comment has been minimized.

Show comment
Hide comment
@varkor

varkor Aug 20, 2018

Contributor

also: can cargo fix fix these? not a blocker, but would be nice

So far, there's no standard treatment of "deprecated in favour of", which would be required for cargo fix, in order to offer the correct suggestion (i.e. at the moment the message is just part of the standard reason field). Maybe we could add an extra field to rustc_deprecated, though unless we think it's going to be common for items to be deprecated in favour of being replaced verbatim by a successor (e.g. in the case of a plain rename like this) — we might usually prefer to offer more sophisticated suggestions, so perhaps we want to treat it on a case-by-case basis.

Contributor

varkor commented Aug 20, 2018

also: can cargo fix fix these? not a blocker, but would be nice

So far, there's no standard treatment of "deprecated in favour of", which would be required for cargo fix, in order to offer the correct suggestion (i.e. at the moment the message is just part of the standard reason field). Maybe we could add an extra field to rustc_deprecated, though unless we think it's going to be common for items to be deprecated in favour of being replaced verbatim by a successor (e.g. in the case of a plain rename like this) — we might usually prefer to offer more sophisticated suggestions, so perhaps we want to treat it on a case-by-case basis.

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Aug 29, 2018

Contributor

@rfcbot resolve deprecation-schedule

Seems like there's no further progress to be made from discussing the deprecation schedule. Here's my solution:

  1. I've opened an issue to discuss automating rename deprecations by adding a field to the attribute: #53802
  2. We should make sure to include in the release notes all future deprecations, so that people will see them (that is, these will be in the release notes 3 times before the deprecation actually happens).
Contributor

withoutboats commented Aug 29, 2018

@rfcbot resolve deprecation-schedule

Seems like there's no further progress to be made from discussing the deprecation schedule. Here's my solution:

  1. I've opened an issue to discuss automating rename deprecations by adding a field to the attribute: #53802
  2. We should make sure to include in the release notes all future deprecations, so that people will see them (that is, these will be in the release notes 3 times before the deprecation actually happens).
@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Aug 29, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot commented Aug 29, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

bors added a commit that referenced this pull request Aug 31, 2018

Auto merge of #53533 - withoutboats:error-source, r=withoutboats
Add Error::source method per RFC 2504.

This implements part of RFC 2504.

* Adds `Error::source`, a replacement for `Error::cause` with the "right" signature, which will be instantly stable.
* Deprecates `Error::cause` in 1.33 (this choice was based on the precedent in #52994, which we haven't finalized).
* Redefines `Error::cause` to delegate to `Error::source` (the delegation can only go in this direction, not the other).

@rfcbot fcp merge

bors added a commit that referenced this pull request Sep 1, 2018

Auto merge of #53533 - withoutboats:error-source, r=withoutboats
Add Error::source method per RFC 2504.

This implements part of RFC 2504.

* Adds `Error::source`, a replacement for `Error::cause` with the "right" signature, which will be instantly stable.
* Deprecates `Error::cause` in 1.33 (this choice was based on the precedent in #52994, which we haven't finalized).
* Redefines `Error::cause` to delegate to `Error::source` (the delegation can only go in this direction, not the other).

@rfcbot fcp merge
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton
Member

alexcrichton commented Sep 5, 2018

@bors: r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 5, 2018

Contributor

📌 Commit ff79670 has been approved by alexcrichton

Contributor

bors commented Sep 5, 2018

📌 Commit ff79670 has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 5, 2018

Contributor

⌛️ Testing commit ff79670 with merge 8b7f164...

Contributor

bors commented Sep 5, 2018

⌛️ Testing commit ff79670 with merge 8b7f164...

bors added a commit that referenced this pull request Sep 5, 2018

Auto merge of #52994 - varkor:trim_direction, r=alexcrichton
Add trim_start, trim_end etc.; deprecate trim_left, trim_right, etc. in future

Adds the methods: `trim_start`, `trim_end`, `trim_start_matches` and `trim_end_matches`.
Deprecates `trim_left`, `trim_right`, `trim_left_matches` and `trim_right_matches` starting from Rust 1.33.0, three versions from when they'll initially be marked as being deprecated, using the future deprecation from #30785 and #51681.

Fixes #30459.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 6, 2018

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 8b7f164 to master...

Contributor

bors commented Sep 6, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 8b7f164 to master...

@bors bors merged commit ff79670 into rust-lang:master Sep 6, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@dtolnay dtolnay added the relnotes label Sep 6, 2018

@dtolnay

This comment has been minimized.

Show comment
Hide comment
@dtolnay

dtolnay Sep 6, 2018

Member

Tagging relnotes -- this a future deprecation in 1.33.0 so it will be noted in the next three release notes.

Member

dtolnay commented Sep 6, 2018

Tagging relnotes -- this a future deprecation in 1.33.0 so it will be noted in the next three release notes.

@varkor varkor deleted the varkor:trim_direction branch Sep 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment