I think your assumption, that broadcasting is acting like a loop, is wrong. If this would be the case, it wouldn’t be very efficient and would be just a convenience to write shorter code, which it isn’t. You may try to benchmark it and I predict, broadcasting is faster.
This is what your assignment looks like:
how??? There’s no magic, no matter how there must be a sequence of computations.
noted that the RHS of a[2:4].=view(a,1:3) is a SubArray. That means no copy of a[1:3] is generated and being maintained. So, after the content at the address of a was overwritten by that in a, the next operation (that puts the content pointed by a into the address of a) should be side-effected. I really not understand how the .= assignment works???
The source and destination memory regions overlap so making a copy before executing the statement wouldn’t be unreasonable (to avoid undefined behaviour). Perhaps there is a remark on this in the docs, although I can’t immediately find it.
Of course, in the end, there must be a loop, to copy memory. But it is not the equivalence to looping over the array/view elements. The lowered code implies, that the source and destination is prepared into %2(destination in array) and %5(source view) before looping and moving the data from source to destination.
And than the problems seems to be the call to Base.identity:
This behavior is expected. Broadcasting does unaliasing before making an operation. Other than that broadcast is just a loop (but making sure to produce a correct type and shape of the output and making sure looping is efficient).
I disagree. Syntax wise a[2:4] .= view(a, 1:3); means “put whatever is on the RHS at the time of writing this into the LHS”. Whether that is done with a loop or a memory copy of whole chunks of memory is an implementation detail. The syntax, however, is unambigous. If you want to fill your array (or a slice of it) with a specific value, use fill! (or fill!(view(a, 2:4), ...) instead.
Well, the alternative would be that the end result would depend on the exact order in which the copy (or other operation) is done. Which isn’t a very nice way to specify a language. It would also inhibit certain optimizations the compiler can do, which is what is happening here.
AFAIK the traversal order of broadcasting is undefined on purpose (to allow future optimizations), so you may not want to rely on it even if it appears to work. This could change in some future version of Julia.