Could separating private attribute access help performance?

Internals & Design Internals
1

Suppose Julia distinguished between private and public attributes

struct Foo
  @public u
  a
  b
end

so that public access x.u was allowed but access to private attributes from outside the module needed

getprivate(x, :a)
@privates x.a + x.b

I think this could be nice for distinguishing public from private API.

My question is: could this help the compiler make optimizations, since it could tell statically that I’m not accessing any private properties?

2

I’m not an expert, but I don’t think it would change anything. Why would keeping fields behind a private barrier make it easier to know more? If you can still change them via a getprivate function then they aren’t constant, and also a struct is immutable anyway.

3

I’m no expert either but my understanding is that the key feature from a compiler optimization perspective is whether it is mutable/immutable. That is, the key thing the compiler needs to know ahead of time is whether the type can change, rather than the value. And this is already taken care of by struct versus mutable struct. Probably an over-simplification, but from the compilers point of view, it doesn’t really matter whether your Float64 takes value 1.0 or 2.0. All that matters is knowing ahead of time that it definitely will be a Float64.

The optimizations for things like StaticArrays come from the fact that something that is able to be mutated in a normal Vector (the length) is known to be fixed ahead of time in a StaticArray. Again, it doesn’t matter what values are in the Vector or StaticArray. All that matters is whether it can be treated as mutable/immutable.