# SE-0202: Random Unification **URL:** \ **Category:** Proposal Reviews\ **Created:** [March 23, 2018, 7:57pm UTC](https://forums.swift.org/t/se-0202-random-unification/11313 "2018-03-23T19:57:47Z")\ **Posts on this page:** 1\ **Showing post:** 55
**Author:** ![jarod](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jarod/32/364_2.png) [@jarod](https://forums.swift.org/u/jarod)\ **Post date:** [March 25, 2018, 4:52pm UTC](https://forums.swift.org/t/se-0202-random-unification/11313/55 "2018-03-25T16:52:20Z")
> [@Zhu\_Shengqi](#): > > If it’s common to cause crash if return a non-optional, it’s also common to cause crash when accessing an array element by index. So what’s the difference? I think we shouldn’t sacrifice the usability of an API just because improper use may cause crash. Besides, the random() is consist of two steps: generate a random index and return the element by index. Since a crash always happens when using an index out of bounds to access an element, why return an optional in this API? > > Another strange use case is [1, 2, 3].random()!, which also support my point: user knows how to handle the empty collection case, and we shouldn’t handle this special case for them and return an optional value. In some projects I have worked on it forbids using ! to force-unwrap an optional, it would be disaster to see random() ?? defaultValue in every use case (assume the user knows the collection is not empty). The case for trapping on access by index is well-summarized [here](https://forums.swift.org/t/draft-adding-safe-indexing-to-array/10767/124). The index you're using was calculated in some way, and if it goes out of bounds, there's a serious bug in your logic that shouldn't be handled at run time through a failed optional unwrap. Most of the time that you're working with a collection, you don't have perfect knowledge about its contents. A hard-coded `[1, 2, 3]` is the exception, not the rule, so if `random` traps, then you have to do an emptiness check before using it most of the time. It's safer /and/ more convenient in the common case for the API to do the emptiness check for you. That's not to say that optional element-at-index or non-optional random element APIs would not be useful sometimes, but they should not be the default. For what it's worth, I think the `[1, 2, 3].random()` case would ideally be handled by some kind of type-level support for non-empty collections. But failing that, adding a `!` is a minimal burden on the developer. I've worked on projects that forbid `!` as well, but I think that's a cultural issue in the Swift community that's slowly dying out. The feature exists in the language precisely for cases like this. If allowing `!` is out of your control, it's simple to get the same behavior while bypassing your linter by adding a `Collection` extension that unwraps the random element and `fatalError`s when that fails. --- _[View the full topic](https://forums.swift.org/t/se-0202-random-unification/11313)._