Are there any plans to support determinism in the stdlib collection methods? E.g. by setting/reseeding the internal 

kotlin.random.Random.Default

so that running

listOf(1,2,3).shuffled()

twice would give the same result. Controlling randomess is an important feature of every language that is intended for data-science (see https://www.w3schools.com/python/ref_random_seed.asp for python or https://www.rdocumentation.org/packages/simEd/versions/1.0.3/topics/set.seed for R

I think the Kotlin developers know what the importance of being able to set the seed of an RNG is… you can always build your own RNG instances with a specified seed value (e.g.

val random = Random(42)

), and if “controlling randomness” is important in your application, you should make calls to RNG instances you control instead of relying on the

Random.Default

singleton

I'm aware of that. However, whenever we use some piece of code that includes library calls that use shuffled etc internally, we are loosing determinism.

shuffled()

could be modified to take a

Random

as an argument, with a default of

Random.Default

. However, the library would then have to declare either that it commits to using the same sequence of random-value calls for all future updates, or that the same seed may lead to different results after an update to the stdlib.

We allow controlling randomness of the stdlib functions by providing overloads that take an arbitrary Random instances including deterministic ones. We expect other libraries to follow this convention. We're against providing any guaranties of determinism for

Random.Default

, for example being able to set its seed with some global method. In fact, having such globally mutable seed in a concurrent environment doesn't make further random calls anymore predictable.

Thanks @ilya.gorbunov for this nice explanation. The concurrency argument makes a lot of sense indeed.