[RFC] Rename send to write.

[Dirbaio]

send and write are essentially synonymous. All the traits use write, except nb::spi::FullDuplex, which uses send.

This PR renames it to write. Instances of send in the docs are also replaced, for consistency.

[rust-highfive]

r? @therealprof

(rust-highfive has picked a reviewer for you, use r? to override)

[ryankurte]

lgtm

[eldruin]

This would lead to ambiguous calls for users of the prelude since all traits are pulled in.
The current method names are all different for traits in blocking and non-blocking modes. See for example SPI:

• dev.read() -> nb::spi::Read::read()
• dev.send -> nb::spi::Write::send()
• dev.transfer() -> blocking::spi::Transfer::transfer()
• dev.write -> blocking::spi::Write::write()

Same thing for serial in #280.
Choosing the same name would force users to either stop using the prelude or turbofish calls.
We could also get rid of the prelude, though.

[Dirbaio]

If you look at that "merged" API as a whole, it feels very inconsistent:

• write is blocking, read is nonblocking.
• there's send and write that look like they do the same.

I think having equal names for equivalent blocking/nonblocking methods is much clearer.

About the naming conflicts:

• Hal-agnostic code will use either the blocking or nonblocking trait, but not both, so it won't run into conflicts.
• Code using a particular HAL can avoid the conflict by importing only one trait.
• Also, as per the discussions in Ship a 1.0 release #177 (comment) and Remove try_ prefix. #268 HALs can define inherent methods of the same names with ergonomic improvements (infallible, for example) so end-user code doesn't have to use any e-h trait at all.

Given the above, maybe removing the prelude is a good idea, yup. I don't see it adding ergonomic improvements in either hal-agnostic or hal-using code.

Also, the Rng traits already have read for both blocking and nonblocking :)

[eldruin]

The problem only exists for structs implementing the blocking and non-blocking versions of the traits.
For example, an SPI MCU peripheral. This would implement both versions so that the user can use whatever necessary, hence ambiguity if both traits are imported.
For unrelated traits this is irrelevant because the same struct would not implement both Rng and SPI traits.

[Dirbaio]

This (and #280) was discussed in last week's and today's WG meetings. Minutes:

    * both PRs discussed, so far conclusion is:
            * remove prelude so we can easily have overlapping method names between traits
            * update traits to make send/write/bwrite/etc methods all consistent across blocking/nonblocking traits
            * essentially, approve both these PRs and also remove the prelude

The key question is "should different flavors of the same trait use the same method names?". Arguments in favor and against are pretty much the ones already discussed in this thread.

One argument against is the prelude, the solution is removing it (#282).

[eldruin]

Looks good to me.
Fort the record, the decisive argument for me was that it would be weird when we have 3 different synonyms for write, one for blocking, one for nb, one for futures. So it seems better to remove the prelude and disambiguate if necessary.

[therealprof]

LGTM

bors r+

[bors]

Build succeeded:

• ci-linux (1.35.0, x86_64-unknown-linux-gnu)
• ci-linux (stable, thumbv6m-none-eabi)
• ci-linux (stable, thumbv7m-none-eabi)
• ci-linux (stable, x86_64-unknown-linux-gnu)
• fmt