make .= return its right hand side. fixes #25954

[JeffBezanson]

This is a really simple, sub-optimal solution to try to get the right behavior in place quickly. The hack is to lower .= both ways (the usual broadcast fusion way, and the version that saves the RHS in a temporary variable), and select one at the point where we know whether the expression's value is used.

If we want, the same mechanism could instead be used to give an error for using the value of .=, if we'd rather not decide now.

[JeffBezanson]

Fixes #25954

[stevengj]

Since the whole point of .= is to avoid allocating temporaries, defining it to return its LHS makes a lot more sense to me. I don't understand the insistence that it should behave like = in its return value when it behaves differently from = in other ways, anyway.

In what circumstance is returning the RHS, i.e. allocating a temporary that the user presumably chose .= to avoid, a desirable behavior? What practical problem does this PR solve?

[JeffBezanson]

That's a good question. It's hard to say, since there are almost no (maybe actually zero?) examples of code that uses the value of .=.

One possible use is a .= b .= c, where the shapes of a and b are each compatible with c, but not with each other.

Another issue is that e.g. A[:,:] = 0 returns 0, so it's surprising for A .= 0 to return an array.

[stevengj]

Returning the LHS lets you chain the .= assignment with additional in-place functions like sort!

If you expect the RHS to be broadcasted, it’s not so strange that it changes shape—this is what broadcasting does.

[JeffBezanson]

It can change type as well as shape. In a .= b .= pi, a would be initialized to pi converted to the element type of b, instead of the original pi.

[stevengj]

That's true. I still don't see it as a big problem. If someone writes a .= b .= sin.(c) they are clearly trying to avoid allocating temporary arrays. They won't be grateful if we allocate sin.(c) in order to return the RHS to prevent it from passing through conversion to eltype(b).

.= is already fundamentally different from = in lots of ways. Defining it to return the LHS seems much more practically useful, and consonant with the in-place-fusing purpose of .=, than returning the RHS (possibly allocating an unwanted copy).

Defining it to return the RHS seems to fundamentally conflict with the purpose of .=, which is to avoid allocating temporary arrays. I don't think the (largely hypothetical) benefits are worth this price.

[mbauman]

It's hard to say, since there are almost no (maybe actually zero?) examples of code that uses the value of .=.

I'm not so sure about that. There are no registered packages with single lines of code with a = b .= c or a .= b .= c, but there are 11 examples of return y .= …, and I'd bet even more implicit returns. And there's also the use of the expression within function calls like the mul!(x, y.*=2) example in the issue thread.

I could get behind an error here.

[stevengj]

@mbauman, in all of the examples you cite, it sounds like returning the LHS is the desired behavior. This makes total sense to me, because using .= means "I don't want the RHS to be materialized."

[mbauman]

I mean, it is that way because that's the way it is. I do agree that this could result in unexpected allocations and double-execution of a RHS broadcast, which is strange and unfortunate. On the other hand, this seems strange to me:

julia> function f(x)
           local a::Any
           local b::Int
           a = b = x
           (a, b)
       end
f (generic function with 1 method)

julia> f(2.)
(2.0, 2)

julia> function g(x)
           a = Array{Any}(uninitialized, 1)
           b = Array{Int}(uninitialized, 1)
           @. a = b = x
           (a, b)
       end
g (generic function with 1 method)

julia> g([2.])
(Any[2], [2])

[JeffBezanson]

From triage: I'll add a deprecation warning for this (and therefore not change the behavior), since that would be the usual course of action anyway, and then we can decide later whether to change it or turn the warning into an error.

[StefanKarpinski]

There are two cases essentially:

1. a = b .= f.(c, d)
2. a .= b .= f.(c, d)

In the first case, b already captures the value of the LHS of the .= so returning that buys nothing – the only thing you might want is to capture the RHS but also assign into b in place. In the second case, there's no reason why any temporary would need to be allocated: in place assignment into a and b could be done minimally by evaluating the right loops. So I find the argument for returning the LHS to avoid unnecessary temporaries unconvincing – returning the LHS is useless in one case and no more efficient in the other case.

On the other hand, evaluating the RHS is consistent with the behavior of =. It also makes case 1 above actually useful instead of redundant since a and b can capture different things (and could arguably be written more clearly as b .= (a = f.(c, d)) assuming that would actually fuse). @mbauman's argument above shows why evaluating to the LHS in case 2 would be confusing in that the type of b would affect the value of a via spooky action at a distance. This situation is no different than the situation for a = b = f(...). Neither the LHS nor the RHS evaluation behavior actually inherently entails more allocation and evaluating to the RHS is more consistent with the rest of the language and has less potential for spooky action at a distance hazard.

Overall, I have a hard time seeing valid arguments for returning the LHS versus the RHS.

[stevengj]

If you define:

function f!(x)
     x .= foo.(x)
end

shouldn't it return the LHS (x) rather than allocating another array and returning foo.(x)?

If you do a function call

sort!(x .= x.^2)

shouldn't it call sort! on x, and not on a new array of x.^2?

These, to me, are more realistic uses of the value of .=, rather than explicit a = b .= c or a .= b .= c expressions. Returning the RHS defeats the purpose of using .=.

[mbauman]

I just have a hard time seeing how that's any different from:

julia> function f()
           local x::Int
           x = 2.0
       end
f (generic function with 1 method)

julia> f()
2.0

Or:

julia> function settwototwo!(x)
           x[2] = 2
       end
settwototwo! (generic function with 1 method)

julia> settwototwo!([4,3,2])
2

[stevengj]

Because the whole point of .=, almost the only reason to use it, is to avoid allocating the right-hand-side? Because it is defined to be sugar for broadcast!?

The question is, are there any practical circumstances where the users of .= will be happy if you allocate the RHS in order to return it? Or will basically all users of .= be annoyed by this behavior?

Would you be happy if you wrote return x .= sin.(y) or sort!(x .= sin.(y)) and it returned a new array rather than x?

[JeffBezanson]

It just means you need to write x .= sin.(y); return x instead of return x .= sin.(y).

[stevengj]

Sure, there is a workaround. There is also a workaround if you want the RHS. That doesn’t address the question of which behavior is more useful.

[JeffBezanson]

That's true, but it's hard to guess what we would find more useful, so we need to have simple rules like "assignments always return the RHS".

Anyway, I believe this is used quite rarely, so I'll proceed with just deprecating it. That way there's no final decision yet.

[mbauman]

I'm getting false positives in #24368 with code like this:

$ ./julia --depwarn=error -q
julia> module TestFoo
           x .= y
           nothing
       end
ERROR: syntax: Deprecated syntax `using the value of `.=``.