Vec: looks like is_empty and len are not needed

[tshepang]

The slice module already implements these methods

[rust-highfive]

r? @alexcrichton

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

[tshepang]

Does my change break anything? make check succeeds (on my Debian machine).

[Gankra]

No this seems totally legit (although it probably forced the optimizer do a bit more work on these methods...).

[Gankra]

@bors r+

[bors]

📌 Commit 42b46d2 has been approved by Gankro

[petrochenkov]

I will break code using Vec::len or Vec::is_empty as function objects:

fn main() {
    let vecs = vec![vec![1], vec![1, 2], vec![1, 2, 3]];
    for len in vecs.iter().map(Vec::len) { // <- No autoderef happens here, len is not found
        println!("{}", len);
    }
}

[Gankra]

Woah! I didn't realize we had implemented that!

On Sat, Jul 11, 2015 at 6:47 PM, Vadim Petrochenkov <
notifications@github.com> wrote:

I will break code using Vec::len or Vec::is_empty as function objects:

fn main() {
let vecs = vec![vec![1], vec![1, 2], vec![1, 2, 3]];
for len in vecs.iter().map(Vec::len) { // <- No autoderef happens here, len is not found
println!("{}", len);
}
}

—
Reply to this email directly or view it on GitHub
#26980 (comment).

[Gankra]

@bors r-

Want to think about this then

On Sat, Jul 11, 2015 at 7:00 PM, Alexis Beingessner <a.beingessner@gmail.com

wrote:

Woah! I didn't realize we had implemented that!

On Sat, Jul 11, 2015 at 6:47 PM, Vadim Petrochenkov <
notifications@github.com> wrote:

I will break code using Vec::len or Vec::is_empty as function objects:

fn main() {
let vecs = vec![vec![1], vec![1, 2], vec![1, 2, 3]];
for len in vecs.iter().map(Vec::len) { // <- No autoderef happens here, len is not found
println!("{}", len);
}
}

—
Reply to this email directly or view it on GitHub
#26980 (comment).

[reem]

Seems we just cannot do this.

[tshepang]

Does this mean the test suite is incomplete @petrochenkov?

[retep998]

@tshepang The test suite is always incomplete. There are numerous ways to cause breaking changes in Rust without tripping the test suite. That's why PRs are manually reviewed and brson does crater runs on occasion to see if anything on crates.io broke.

[nagisa]

You can’t just remove these methods without deprecating them either. I’d propose deprecation of these two functions as an RFC.

[Gankra]

This super isn't worth it. They're two stupid little functions that have 0 maintenance burden.

Thanks anyway, @tshepang!

[tshepang]

@nagisa if they are deprecated, how would one use the non-deprecated ones? Won't the deprecated ones mask those that are not deprecated?

@gankro do you think these methods are just an oversight?