slice::fill documentation does not mention usage with uninitialized memory

[FreezyLemon]

Location

https://doc.rust-lang.org/std/primitive.slice.html#method.fill

Summary

slice::fill has an alias memset which implies it can be used when self's underlying memory is uninitialized.

The description for slice::fill is very short and does not mention this use case, so it seems unclear if this is intended behaviour or not. Some external discussions already mention the function as a safe way to initialize memory with a T: Clone type.

[saethlin]

slice::fill has an alias memset which implies it can be used when self's underlying memory is uninitialized.

That would contradict the documentation for addr_of!, which clearly identifies such usage as UB: https://doc.rust-lang.org/1.75.0/core/ptr/macro.addr_of.html (though that limitation will probably not exist forever, this topic is discussed constantly, for example #119241 (comment))

Some external discussions already mention the function as a safe way to initialize memory

I don't see any mention of uninitialized memory in the linked discussion?

[Noratrieb]

slice::fill has an alias memset which implies

Documentation aliases don't imply anything. They just help people find stuff they might want. Someone might want to set some bytes in a slice which they'd do with memset in C, so having an alias might help them to find what they need. But doc aliases don't suggest that the function is actually always equivalent to the aliased function.

[the8472]

If you have uninitialized memory you can refer to it as &mut [MaybeUninit<T>] and then slice::fill that with a MaybeUninit<T> value. But you shouldn't use that for !Copy values.

[FreezyLemon]

Uh, ok. I guess I mixed something up there. I saw the RFC for the somewhat related copy_from_slice which included fill at some point. That did include a mention of using it for safely initializing memory, and I assumed the later implementation still carried this feature.

Based on that assumption I thought this was an oversight in the docs or something, but if that's not the behaviour anyways, the entire issue is invalid.