add #[doc(alias="flatmap")] to Option::and_then

[Dante-Broggi]

I keep forgetting that rust calls this and_then and trying to search for flatmap. and_then's docs even mention "Some languages call this operation flatmap", but it doesn't show up as a result in the search at https://doc.rust-lang.org/std/?search=flatmap

[rustbot]

r? @joshtriplett

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[est31]

The relevant section of the policy:

we don't expect that people are currently searching Rust documentation for language-specific names from arbitrary languages they're familiar with, and we don't want to add that as a new documentation search feature; please don't add aliases based on your favorite language. Those mappings should live in separate guides or references. We do expect that people might look for the Rust name of a function they reasonably expect to exist in Rust (e.g. a system function or a C library function), to try to figure out what Rust called that function.

IMO that policy is too strict and this PR should be merged, but I think due to the policy, it means that this PR can't add flatmap, because it is neither a C library function, nor an assembly name, nor a system function.

Prior PRs like #81989 for example were rejected, but those were much larger in scope than this one so idk, maybe flatmap can get an exception.

[joshtriplett]

I think this follows the policy: it seems reasonable to me that someone might search for "flatmap" in the Rust documentation expecting to find it.

@bors r+ rollup

[bors]

📌 Commit 7fb34c9 has been approved by joshtriplett

It is now in the queue for this repository.