Remove AsyncRead::initializer

[Nemo157]

The tracking issue for std::io::Read::initializer makes it sound like that API is definitely going to be changed a lot, it would be good to remove the similar API here until the std API is closer to its final form.

[cramertj]

Yeah, it seems like there's some push towards having freeze() instead. cc @seanmonstar @RalfJung

[RalfJung]

There was a push at rust-lang/rust#58363, but there are two issues with this:

• Having freeze with the desired semantics basically means that a program can observe uninitialized memory without causing UB. See https://www.reddit.com/r/rust/comments/apreqi/ucgmiri_allhands_2019_recap/egarzl8/ for some links.
• freeze cannot actually be a NOP; uninitialized memory can actually be unstable.

Note however that the current initializer API is incompatible with rust-lang/unsafe-code-guidelines#77, at least if rust-lang/unsafe-code-guidelines#71 ends up deciding that integers must be initialized to be valid.

[seanmonstar]

It seems to me like we're at an awkward point with regards to the desired functionality here.

• If it's decided that &mut [u8] to uninitialized memory is UB, then we need to add methods like unsafe fn read_uninit(&mut self, buf: &mut MaybeUninit<[u8]>).
• However, if it is decided to NOT be UB, then we don't need those methods, and don't need to suffer the churn.

[Nemo157]

Whether or not an &mut [u8] pointing to uninitialized memory is UB, there was earlier discussion in the tracking issue about how the ceremony in the current API doesn't provide much utility and it could be replaced with a simpler API. It would be disappointing if AsyncRead ended up with a different, more complicated API than Read.

[taiki-e]

I think we should choose one of the following:

• Replace with a simpler API like Tracking issue for Read::initializer rust#42788 (comment)
• Make AsyncRead::initializer unstable API - this will be near to what std is doing.
• Do both of the above.

[cramertj]

+1 for making it unstable. The "simpler API" is unsound, though, so I don't want to do that.

[carllerche]

@cramertj what is unsound about it?

[cramertj]

unsafe fn may_read_buffer(&self) -> bool { true } is incorrect because it is unsafe to implement, not unsafe to call. The only way today to make something unsafe to implement is via a separate unsafe trait, or something which is forced to call an unsafe function, at which point you wind up back at the current initializer API.

[carllerche]

@cramertj makes sense, thanks for the explanation. Is the intent to document the unsafe requirements you describe as part of https://github.com/rust-lang/unsafe-code-guidelines or some other location?

[cramertj]

The requirement that unsafe fn in traits is only unsafe to call, not unsafe to implement? I'm not aware of an existing UCG proposal for that, but I'd certainly be interested in one, yes.

[RalfJung]

That seems more like Reference material than UCG. There's no open questions, just things are a bit surprising (rust-lang/rfcs#2585 would improve things IMO by making the role of unsafe fn clearer).