field/property accessors for StaticSymbol

[Tokazama]

This provides some additional support for field and property accessors using StaticSymbol. I didn't find any increased invalidations on several versions of Julia, so hopefully that holds up with the new invalidation action we have.

@cscherrer, you might be interested in this

[codecov]

Codecov Report

Merging #83 (ad58f52) into master (e817b87) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #83      +/-   ##
==========================================
+ Coverage   99.32%   99.34%   +0.02%     
==========================================
  Files           1        1              
  Lines         447      461      +14     
==========================================
+ Hits          444      458      +14     
  Misses          3        3              

Impacted Files	Coverage Δ
src/Static.jl	99.34% <100.00%> (+0.02%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[Tokazama]

@chriselrod is this breaking LV? The other integration failures seem unrelated to this PR

[chriselrod]

Tests passed locally, but I don't get the point of supporting this.
Is calling getproperty(obj, x) where x was an argument to the function a common pattern?

[Tokazama]

It's for applications similar to Setfield and Accessors where constant propagation of a symbol fails for access to nested fields.

[cscherrer]

For named tuples, Base.merge is not type-stable for nested structures. It uses if @generated, which seems to allow the compiler to give up very early on type inference.

I've solved this in my packages by defining an alternate function to use instead of merge that's always generated (so no type-unstable fallback). I'd file an issue about this, but I so often see compiler speed favored over strong type inference, so I'm not sure it would be well-received.

Just mentioning in case that could also be an issue here.

[Tokazama]

Do you have a mwe example where this fails so I can have a test that avoids this?

[cscherrer]

Also worth considering: Should this be

function Base.setindex(nt::NamedTuple{N,T}, v, ::StaticSymbol{S}) where {S,N,T}

?

That would help it to specialize for the NamedTuple, which may help merge instability be a non-issue. Details here in the Julia docs.

The tricky thing with all of this is that the compiler makes so few guarantees. Type stability is very context-dependent, even depending on what's been compiled so far. So code that seems fine when I write it can have subtle problems downstream.

Sorry this comment is so long. As might be obvious, I think there are lots of open questions around this kind of thing.

[cscherrer]

Do you have a mwe example where this fails so I can have a test that avoids this?

No, I guess it's more of a "this might bite us". But then again, it may not. That's the problem with lack of compiler guarantees :)

Maybe the best way to handle this is to leave the code as-is, but add a comment to make it easier later in case this becomes a problem. I think I'd point to the specialization link in the docs and mention the fact that if @generated in Base.merge can lead to type instability.