# Broadcast scalar deprecation warnings
**URL:** https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981
**Category:** General Usage
**Created:** [June 26, 2018, 9:34pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981 "2018-06-26T21:34:06Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@tkoolen](https://discourse.julialang.org/u/tkoolen)
#### Post date: [June 26, 2018, 9:34pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/1 "2018-06-26T21:34:06Z")
How are others that are updating packages dealing with deprecation warnings like
```julia
┌ 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](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.
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [June 26, 2018, 9:39pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/2 "2018-06-26T21:39:16Z")
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:
```julia
if VERSION <= v"0.7-"
⊙(x) = x
else
⊙(x) = Ref(x)
end
```
---
### Author:  [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [June 26, 2018, 9:48pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/3 "2018-06-26T21:48:12Z")
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…)
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [June 26, 2018, 9:52pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/4 "2018-06-26T21:52:20Z")
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 `@.` - #2 by rdeits](https://discourse.julialang.org/t/recent-broadcast-changes-iterate-by-default-scalar-struct-and/11178/2)
---
### Author:  [@tkoolen](https://discourse.julialang.org/u/tkoolen)
#### Post date: [June 26, 2018, 10:05pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/5 "2018-06-26T22:05:26Z")
> [@rdeits](#):
>
> when you use `@.` your `Ref(x)` wrappers turn into `Ref.(x)` ,
Good to know, thanks!
> [@fredrikekre](#):
>
> I like wrapping in a 1-tuple.
> [@rdeits](#):
>
> Unfortunately, tuple wrappers of non-bits types still allocate on v0.6
Yeah, that’s going to prevent me from using them during the transition period, but doesn’t seem too bad after.
---
### Author:  [@tlnagy](https://discourse.julialang.org/u/tlnagy)
#### Post date: [September 5, 2018, 6:25pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/6 "2018-09-05T18:25:40Z")
Did anyone figure out how to track the line numbers down for these errors? We just ran into this when updating `Gadfly.jl`: [https://github.com/GiovineItalia/Compose.jl/pull/282#issuecomment-418698874](https://github.com/GiovineItalia/Compose.jl/pull/282#issuecomment-418698874)
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [September 5, 2018, 6:44pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/7 "2018-09-05T18:44:10Z")
Using `--depwarn=error` usually works well.
---
### Author:  [@tkoolen](https://discourse.julialang.org/u/tkoolen)
#### Post date: [September 5, 2018, 10:08pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/8 "2018-09-05T22:08:54Z")
Any idea why that’s happening in the first place?
---
### Author:  [@tlnagy](https://discourse.julialang.org/u/tlnagy)
#### Post date: [September 7, 2018, 10:28pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/9 "2018-09-07T22:28:25Z")
Yeah, what was the rationale for this change?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [September 7, 2018, 11:53pm UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/10 "2018-09-07T23:53:41Z")
Lots of stuff to dig up in [recent broadcast changes (iterate by default), scalar struct, and `@.`](https://discourse.julialang.org/t/recent-broadcast-changes-iterate-by-default-scalar-struct-and/11178) and references therein.
---
### Author:  [@tkoolen](https://discourse.julialang.org/u/tkoolen)
#### Post date: [September 8, 2018, 3:02am UTC](https://discourse.julialang.org/t/broadcast-scalar-deprecation-warnings/11981/11 "2018-09-08T03:02:35Z")
Sorry, I was referring specifically to the line numbers being incorrect for these errors, which I think was not discussed in that topic.