Right now the units and constants for symbolic dimensions, like the one you get from us"km", are stored with mutable arrays (note that non-symbolic versions like u"km" are fine as-is).
This is part of the reason it takes so long to generate all of the constants, which is why they are created at first call to sym_uparse, rather than at precompilation time. This is why the first time you call us"km", it takes a little longer. It's also why you can't precompile things with symbolic dimensions (see #58).
I think it might make sense instead to have an immutable version of each of the symbolic units and constants. I'm not quite sure how this would work. Maybe you could have another SymbolicImmutableDimensions <: AbstractDimensions that is explicitly for storing symbolic dimensions constants, and stores the symbol.
Then you could have promotion rules set up so it will convert itself to SymbolicDimensions when operated on. But maybe there is a simpler way.
Right now the units and constants for symbolic dimensions, like the one you get from
us"km", are stored with mutable arrays (note that non-symbolic versions likeu"km"are fine as-is).This is part of the reason it takes so long to generate all of the constants, which is why they are created at first call to
sym_uparse, rather than at precompilation time. This is why the first time you callus"km", it takes a little longer. It's also why you can't precompile things with symbolic dimensions (see #58).I think it might make sense instead to have an immutable version of each of the symbolic units and constants. I'm not quite sure how this would work. Maybe you could have another
SymbolicImmutableDimensions <: AbstractDimensionsthat is explicitly for storing symbolic dimensions constants, and stores the symbol.Then you could have promotion rules set up so it will convert itself to
SymbolicDimensionswhen operated on. But maybe there is a simpler way.Thoughts @gaurav-arya @devmotion?