# Should a.b lower to getproperty(a, Val{:b})?

**URL:** <https://discourse.julialang.org/t/should-a-b-lower-to-getproperty-a-val-b/10449>\
**Category:** Internals & Design\
**Created:** [April 20, 2018, 3:00am UTC](https://discourse.julialang.org/t/should-a-b-lower-to-getproperty-a-val-b/10449 "2018-04-20T03:00:06Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![benninkrs](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/benninkrs/32/3191_2.png) [@benninkrs](https://discourse.julialang.org/u/benninkrs)\
**Post date:** [April 20, 2018, 3:00am UTC](https://discourse.julialang.org/t/should-a-b-lower-to-getproperty-a-val-b/10449/1 "2018-04-20T03:00:06Z")

</div>

I am very happy that in 0.7 the expression `a.b` lowers to an overloadable function. But I am a bit surprised that it lowers to `Base.getproperty(a, :b)` and not `Base.getproperty(a, Val{:b})`. It seems that the latter would be much better for taking advantage of Julia’s powerful dispatch. In the PR that introduced the new lowering, @kristoffer.carlsson [makes a similar point](https://github.com/JuliaLang/julia/pull/24960#issuecomment-349978153) and @jeff.bezanson [acknowledges the possibility of using Val{:b}](https://github.com/JuliaLang/julia/pull/24960#issuecomment-350433287), but it seems the discussion of this particular point went no further.

(Similar comments apply to `Base.setproperty!`).

---

<div class="post-metadata">

**Author:** ![Keno](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/keno/32/285_2.png) [@Keno](https://discourse.julialang.org/u/Keno)\
**Post date:** [April 20, 2018, 4:23am UTC](https://discourse.julialang.org/t/should-a-b-lower-to-getproperty-a-val-b/10449/2 "2018-04-20T04:23:35Z")

</div>

The feature came combined with compiler enhancements that made it possible for it to properly infer `getproperty(a, :b)` (as long as the field argument is constant). `Val{:b}` would force method specialization that is generally not desired here. Of course it is always possible to implement `getproperty(a::MyType, b::Symbol) = getproperty(a, Val{b}())` if you want that for some reason.

---

<div class="post-metadata">

**Author:** ![benninkrs](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/benninkrs/32/3191_2.png) [@benninkrs](https://discourse.julialang.org/u/benninkrs)\
**Post date:** [April 20, 2018, 3:16pm UTC](https://discourse.julialang.org/t/should-a-b-lower-to-getproperty-a-val-b/10449/3 "2018-04-20T15:16:11Z")

</div>

Why do you say that specialization is generally undesired? From a programming perspective, I think I would almost always want different methods for different properties. And in the rare case I didn’t it would be easy to forward to a common method.

---

<div class="post-metadata">

**Author:** ![sdanisch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sdanisch/32/1406_2.png) [@sdanisch](https://discourse.julialang.org/u/sdanisch)\
**Post date:** [April 20, 2018, 8:01pm UTC](https://discourse.julialang.org/t/should-a-b-lower-to-getproperty-a-val-b/10449/4 "2018-04-20T20:01:40Z")

</div>

I think specialisation is unwanted from a compiler standpoint - not from the user perspective.  
We already have compile time problems in Julia and specialisation is expensive. Making a much used feature like getfield heavily specialize on a symbol would add a lot of compilation overhead.

---

<div class="post-metadata">

**Author:** ![benninkrs](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/benninkrs/32/3191_2.png) [@benninkrs](https://discourse.julialang.org/u/benninkrs)\
**Post date:** [April 20, 2018, 8:17pm UTC](https://discourse.julialang.org/t/should-a-b-lower-to-getproperty-a-val-b/10449/5 "2018-04-20T20:17:01Z")

</div>

That makes sense. Now that I know there is a good reason for using symbols, and that doing so will not incur a dispatch overhead, I am content to use the workaround suggested by @Keno for those types whose properties I want to specialize.