The core team recently discussed the amendments proposed in this review thread:
We decided to accept the proposed amendment to remove
randomElement as a customization point.
randomElement remains as public API as a generic extension method on
Collection. The core team was concerned about adding the other proposal's proposed
randomIndex customization point as public API, due to the confusion it could sow and its potential for misuse, and considered having it as pseudo-private standard library API to be ineffective at the problem it's trying to solve, since it would at that point only be adoptable by standard library collection; if we only wanted to accommodate overlarge collections of a closed set of types like
Range, we could do so with control flow within the
randomElement implementation without a generalized customization point in the protocol. Many users expressed concerns about the fact that a generic implementation of
randomElement would crash when invoked on a collection with more than
Int.max elements, and the core team shares these concerns, but is willing to take a wait-and-see approach to see whether it warrants a response in practice. The trap on large
Ranges and other collections can be addressed in the future in an ABI-compatible way by a number of means.