deprecate rand! etc. in favor of x .= rand.()?

[stevengj]

Since we can now do x .= rand.() to evaluate rand() for each element of x, do we still need rand! etcetera?

See also #12277.

[stevengj]

(Though rand!() does have an optimized SIMD implementation IIRC.)

The argument is similar for deprecating fill!(a, x) in favor of a .= x and scale!(a, x) in favor of a .*= x.

[KristofferC]

Can't the specific broadcast function that x .= rand.() lowers into be overloaded to use the optimized version?

[stevengj]

Yes, it can. Of course, it won't work if you fuse the rand.() with additional operations.

[KristofferC]

Yes, but that should be fine I think. You couldn't used the optimized one if you wrote the fused version manually anyway, right?

[stevengj]

Right.

[TotalVerb]

Can one replace use cases like rand!(similar(X)) with similar(X) .= rand.()? I suspect this is possible, though perhaps not as readable.

[stevengj]

@TotalVerb, that would work. I agree it's more verbose, but I don't think that construct is very common; I can only find two packages that use it in test scripts, and in both cases they could have used rand(size(X)...) as well.

[stevengj]

On the other hand, x .= rand.() is not a drop-in replacement for rand!(x) if eltype(x) != Float64, so I think probably we should keep rand!.

(The argument for replacing fill! and scale! remains, however.)

[Sacha0]

On the other hand, x .= rand.() is not a drop-in replacement for rand!(x) if eltype(x) != Float64, so I think probably we should keep rand!.

Though slightly more verbose, perhaps x .= rand.(eltype(x)) with appropriate rand(::Type{...}) methods could work?

(The argument for replacing fill! and scale! remains, however.)

Perhaps fill! and scale! deserve dedicated issues? (Edit: Discussion relevant to fill! in #19598 (comment).) Best!

[Sacha0]

(Also relevant to randn! and randexp!.)