How are others that are updating packages dealing with deprecation warnings like
┌ Warning: broadcast will default to iterating over its arguments in the future. Wrap arguments of
│ type `x::DirectedGraph{Vertex{Int64},Edge{Float64}}` with `Ref(x)` to ensure they broadcast as "scalar" elements.
│ caller = ip:0x0
└ @ Core :-1
on 0.7 for arguments that you just want to have treated as scalars? Actually wrapping everything in Ref is ugly and causes allocations on 0.6 (I’d like to have at least one transitional release that supports both 0.6 and 0.7, among other things for a fair performance comparison). Implementing broadcastable(x::T) = Ref(x) for all of the types used as scalars in broadcasts is the other option, and is better. But I must say that I’m not a big fan of either. I realize it’s probably too late to make changes, but I guess I’m with @stevengj’s comment here: https://github.com/JuliaLang/julia/issues/18618#issuecomment-360629879.
Also, what’s up with the line numbers for this particular depwarn? Most of the time they’re correct, but in this case it’s hard to figure out where the broadcast operation is happening.
Yeah, I don’t love this change either but I’m hoping to be proven wrong (I strongly disliked the f.(x) notation when it was proposed for v0.5 and I was super duper wrong).
How about picking your favorite unicode character that looks…scalar-ish…and doing:
if VERSION <= v"0.7-"
⊙(x) = x
else
⊙(x) = Ref(x)
end
The only difference is that when you use @. your Ref(x) wrappers turn into Ref.(x), which is to say they stop actually working as scalarizers (the same problem applies to my suggestion above). Tuple wrappers don’t have this problem, and I’m hoping we’ll get the & syntax to explicitly scalarize even in the presence of @..
Unfortunately, tuple wrappers of non-bits types still allocate on v0.6, so they don’t solve the original problem.