Broadcast scalar deprecation warnings

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:

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
  ⊙(x) = Ref(x)

I like wrapping in a 1-tuple. IMO it looks better and is a bit more intuitive. (And it should be equivalent to using Ref I think…)

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.

Edit: see also recent broadcast changes (iterate by default), scalar struct, and `@.`

1 Like

Good to know, thanks!

Yeah, that’s going to prevent me from using them during the transition period, but doesn’t seem too bad after.

Did anyone figure out how to track the line numbers down for these errors? We just ran into this when updating Gadfly.jl:

Using --depwarn=error usually works well.


Any idea why that’s happening in the first place?

Yeah, what was the rationale for this change?

Lots of stuff to dig up in recent broadcast changes (iterate by default), scalar struct, and `@.` and references therein.

Sorry, I was referring specifically to the line numbers being incorrect for these errors, which I think was not discussed in that topic.