@safe'ty of find and canFind

Change find's tests to validate usability of @safe.
Eliminate the trustedFindRR case by pushing it down a layer in the find stack of functions.
Mark unpredictableSeed as @trusted (@safe is a stretch due to all the casting) so that it can be used in @safe contexts.
Mark canFind's tests to validate usability of @safe (which lead to the unpredictableSeed change)
On 18/10/14 19:09, monarch dodra wrote:
> In std/random.d:
>
>> @@ -1114,7 +1114,7 @@ auto n = rnd.front;
>>  ----
>>  */
>>
>> -@property uint unpredictableSeed()
>> +@property uint unpredictableSeed() @trusted
>
> Works for me, I was just bringing it up since I still remembered it. I think it
> makes sense that it be useable in safe code. @WebDrake
> <https://github.com/WebDrake> : Are you opposed to this here?

My concern is pretty much as I stated in #2051; it's less to do with the safety 
or trustability of _this_ `unpredictableSeed`, more about whether we could keep 
that promise with other, perhaps more sophisticated implementations.  But that's 
perhaps a problem to worry about if and when we encounter it.

So, I don't see any reason to block this change if the general consensus is that 
the method is memory-safe.  (I'm a little worried, though, that the motivation 
was to allow @safe unittests rather than by any actual library requirement for 
`unpredictableSeed` to be @safe-compatible.)

N.B. this should be revisited at some point to see if we can shift the 
`@trusted` upstream to the methods `that unpredictableSeed` depends on, and just 
mark `unpredictableSeed` itself as `@safe`.