Change:
/// // elements to produce is the length of array down there: only arrays of /// // equal lengths can be compared, so the const generic parameter `N` is /// // inferred to be 5, thus creating array of 5 elements. <ins> /// </ins> /// let array = core::array::from_fn(|i| i); <ins> /// // indexes are:    0  1  2  3  4 </ins> /// assert_eq!(array, [0, 1, 2, 3, 4]); <ins> /// /// let array2: [usize; 8] = core::array::from_fn(|i| i * 2); /// // indexes are:     0  1  2  3  4  5   6   7 /// assert_eq!(array2, [0, 2, 4, 6, 8, 10, 12, 14]); /// /// let bool_arr = core::array::from_fn::<_, 5, _>(|i| i % 2 == 0); /// // indexes are:       0     1      2     3      4 /// assert_eq!(bool_arr, [true, false, true, false, true]); </ins> /// ``` #[inline] #[stable(feature = "array_from_fn", since = "1.63.0")]

Discussion:
and The documentation for states It is not clear what "current array index" refers to, since the function description doesn't necessarily indicate that there is iteration happening to create the resulting array. Additionally, the first line summary doesn't actually reflect the behavior of the function at all. It mentions "the cb call" -- as if there is only one call to . I think would be more clear if the documentation somehow mentioned that the -th element in the output array is the result of calling . The function is similarly unclear. Anyone have thoughts on this? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'm not sure if the section helps, since it separates the description of the callback somewhat. I think it should all be at the same visual level. Juxtaposing next to "array element" also seems weird. How about: Creates an array of type , where each element is the result of calling with that element's index. (Maybe "returned value from" instead of "result of"?)
They're both the same function (std is a re-export of the core one), so is a sufficient link. I agree the "Arguments" section is pretty unusual (I don't remember seeing it on anything else), and I'm not sure that "callback" is a usual word here.  looks like it just uses for the generator, FWIW. The "Examples" section does, I think, really help clarify what it's going to do. But both the prose and the examples could due with some expansion. For example, this should probably get a guarantee of the order in which the items are generated, since it takes , and a corresponding example, though additional guarantees like that take a libs-api sign-off. Oh, and I might as well cc , which is open with some other suggested improvements.
I don't know about how best to document the type inference in the other issue (though, to throw my 2¢ in, I'm not sure it needs documentation :), but you raise a good point about and ordering. Assuming the guarantee of the order of arguments: Creates an array of type , where each element is the result of calling with that element's index.

It is guaranteed that the index ranges from 0 to the end of the array. Is "the end of the array" interchangeable with ? Is clearer? I'm also unsure about explicitly mentioning the index 0 because of zero-length arrays. Instead of explicitly using numbers, maybe an analogue of iteration can be described. I'm not sure if accurately describing that can avoid expose implementation details and/or uninitialized memory, though.
Consider writing out pseudocode as well, as that can be more helpful than prose for some people. For example, you could rename the function to , and describe it as That's pretty accurate, and the should have them understand that it's not literally or or anything. But your note about is a good one. Edge cases are a good thing to mention explicitly even if not strictly necessary. For example, you could mention that "If , an empty array will be returned and the the closure will never be called". You could also describe it by analogy to other things. For example, this is in a way the eager version of .
claim