Deprecated syntax using the value of .= in the REPL.

[fredrikekre]

Example from the manual

julia> x = 1.0:3.0; y = similar(x);

julia> @. y = x + 3 * sin(x)
┌ Warning: Deprecated syntax `using the value of `.=``.
└ @ nothing none:0
3-element Array{Float64,1}:
 3.5244129544236893
 4.727892280477045 
 3.4233600241796016

I suspect this warning comes from setting of the ans variable in the REPL.

[martinholters]

Hm, it's not the assignment to ans (nor showing the result):

julia> a = zeros(4);

julia> "foo"
"foo"

julia> a .= ones(4); ans
┌ Warning: Deprecated syntax `using the value of `.=``.
└ @ nothing none:0
"foo"

julia> ans
"foo"

Also, the work-around is rather ugly: (a .= ones(4); nothing)

Does the REPL split the input at the ; if not in parentheses? Because:

julia> Meta.lower(Main, :(a .= ones(4)))
┌ Warning: Deprecated syntax `using the value of `.=``.
└ @ nothing none:0
:($(Expr(:thunk, CodeInfo(:(begin
      Core.SSAValue(0) = ones(4)
      Core.SSAValue(1) = (Base.broadcast!)(Base.identity, a, Core.SSAValue(0))
      return Core.SSAValue(1)
  end)))))

julia> Meta.lower(Main, :(a .= ones(4); nothing))
:($(Expr(:thunk, CodeInfo(:(begin
      Core.SSAValue(0) = ones(4)
      (Base.broadcast!)(Base.identity, a, Core.SSAValue(0))
      #= REPL[24]:1 =#
      return nothing
  end)))))

Anyway, what would we want to show and assign to ans here?

[stevengj]

I think we should just revert #26088 and return the LHS (see also #25954) as we used to.

[JeffBezanson]

I would also much rather just make a final decision here. This deprecation is a hassle and I'd rather not sink more time into it.

[Keno]

Frankly, I always find the RHS returning behavior at the REPL confusing in any case where the RHS and LHS are not ==, e.g.:

julia> (a,b,c) = Iterators.filter(x->x>3, 1:1000)
Base.Iterators.Filter{getfield(Main, Symbol("##9#10")),UnitRange{Int64}}(getfield(Main, Symbol("##9#10"))(), 1:1000)

[JeffBezanson]

...so we should change the result value of a = b too?

[Keno]

I don't know, but I wanted to mention it, since it seems related. For completeness of examples and to play devil's advocate, do we have a good example (ignoring the mutating assignment variants for now) where returning the LHS would look super strange?

[JeffBezanson]

Are you suggesting a = b showing a different value in the REPL than what the expression actually returns?

[StefanKarpinski]

One option would be to define a = b = c to do a = c; b = c; a and similarly for .=.

[Keno]

No, I'm not suggesting anything. I think my main point is that assignment sometimes does non-trivial transformations (e.g. perform the iteration protocol), esp in the broadcasting cast, and esp in the REPL, you're often more interested in what the result of those transformation is than the value that it was transformed from.

[StefanKarpinski]

@KristofferC has pointed out that mutating operations generally return the thing that's mutating and .= is a mutation operation so the same principle can be argued to apply.

[KristofferC]

(after discussion with @fredrikekre earlier today)

[JeffBezanson]

I'm frankly fine with either choice. However, @mbauman pointed out that the left side is more likely to be a "weird" value, like a view, or a special kind of view we introduce for performance (in the near future, for BitArray), which might make it less useful to return.

This is a special case of a general property of assignment: in a = b, the right side is a normal expression that's evaluated like anything else, but the left side is something weird that's not evaluated, and instead refers to a location in some way. So it's not clear what "the value of the left side" even means, whereas the value of the right side is clear. This is one of the reasons a = b returns b.