# Broadcasting structs as scalars

**URL:** <https://discourse.julialang.org/t/broadcasting-structs-as-scalars/14310>\
**Category:** General Usage\
**Tags:** question\
**Created:** [August 30, 2018, 12:07pm UTC](https://discourse.julialang.org/t/broadcasting-structs-as-scalars/14310 "2018-08-30T12:07:47Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Evizero](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/evizero/32/10118_2.png) [@Evizero](https://discourse.julialang.org/u/Evizero)\
**Post date:** [August 30, 2018, 12:17pm UTC](https://discourse.julialang.org/t/broadcasting-structs-as-scalars/14310/4 "2018-08-30T12:17:00Z")

</div>

> [@e3c6](#):
>
> What’s the reasoning for not having something like this as the default for new types?

> [@recent broadcast changes (iterate by default), scalar struct, and \`@.\`](https://discourse.julialang.org/t/recent-broadcast-changes-iterate-by-default-scalar-struct-and/11178/15):
>
> There’s also a number of asymmetries here: In the future, we’ll iterate over the object or throw an error. You can always treat objects as scalars, but you cannot always treat them as iterables. By defaulting to errors for non-iterables, it’s a great big signal for library creators that they can opt-in to acting like a scalar if it is appropriate. End-users can opt-in to scalar-like behaviors by wrapping in another broadcastable container (like Ref or 1-tuples or 0-dimensional arrays). Were…

---

_[View the full topic](https://discourse.julialang.org/t/broadcasting-structs-as-scalars/14310)._
