Readability improvements

[robertbastian]

This started out as docs improvements, but I've also touched non-docs code now.

let collator: Collator = Collator::try_new(...);

becomes

let collator = Collator::try_new(...);

======

let asdf = foo.iter().map(...).collect::<Vec<_>>();

becomes

let asdf = Vec::from_iter(foo.iter().map(...));

(this shorter, less symbol salad, does into_iter(), and puts the type upfront)

======

let asdf: ZeroMap<u8, u8> = ZeroMap::from_foo();

becomes

let asdf = ZeroMap::<u8, u8>::from_foo();

(this is shorter, and better for refactorings, as the expression has a type)

======

let loc: Locale = "foo".parse().unwrap();

becomes

let loc = "foo".parse::<Locale>().unwrap();

(this is better for refactorings, as the expression has a type)

[sffc]

I think I prefer foo.iter().map(...).collect() because directly using from_iter doesn't chain, which negatively impacts indentation. The rest seem fine.

[sffc]

Also, CI is failing.

[robertbastian]

I think I prefer foo.iter().map(...).collect() because directly using from_iter doesn't chain,

I didn't touch collects without a turbofish.

This often reduces line breaking, many expressions become one-liners.

[sffc]

It seems self-inconsistent that you're changing code to use turbofish in .parse::<Foo>() but not .collect::<Foo>()

[sffc]

Here's a case where we need to increase indentation.

// Max indent 3
        WeekCalculator::try_new(&locale!("und").into())
            .unwrap()
            .weekend()
            .collect::<Vec<_>>(),

// Max indent 4
        Vec::from_iter(
            WeekCalculator::try_new(&locale!("und").into())
                .unwrap()
                .weekend()
        ),

[sffc]

I'm being somewhat picky with this review because the PR is literally entitled "Readability improvements" and I disagree that these are all consistently improvements.

[robertbastian]

It seems self-inconsistent that you're changing code to use turbofish in .parse::() but not .collect::()

I would love to change code to Foo::from_str, but that's not in the prelude, whereas FromIterator is. I think it's more important to have expressions that don't rely on surrounding type context than to avoid turbofishes, because things like let x: Foo = "foo".parse().unwrap(); are a pain during refactorings.

[sffc]

It seems self-inconsistent that you're changing code to use turbofish in .parse::() but not .collect::()

I would love to change code to Foo::from_str, but that's not in the prelude, whereas FromIterator is. I think it's more important to have expressions that don't rely on surrounding type context than to avoid turbofishes, because things like let x: Foo = "foo".parse().unwrap(); are a pain during refactorings.

So it sounds like you would be in support of let x = y.iter().collect::<Foo>(), right? Just not let x: Foo = y.iter().collect()? I'm onboard with that; type inference can cause problems. I just feel that .collect() is more conventional in Rust.

Evidence: 98.8k instances of from_iter( versus 1.3M instances of collect( on Rust GitHub.

[robertbastian]

I'm not a fan of the turbofish if it can be avoided, I prefer using a constructor-like method (like Foo::from_string over .parse::<Foo>()). One issue with collections is that you have to add all generics, so you always end up with .collect::<HashMap<_, _>>(), which is just so many special characters compared to HashMap::from_iter(). I also like that from_iter is explicit about the allocation. In the course of this PR I found a few instances where there are unnecessary chained collects.

[sffc]

It seems we're not in alignment on what is more readable, so I added "discuss-priority"