I understand that there are many implications to consider when promoting
getfield from Core to Base (which will allow overloading of the dot operator)
But I thing at least for dictionaries with keys either symbol or strings it is safe
to add this convenience.
How does one statically know whether the argument is a dictionary or not?
Hopefully you’ve read https://github.com/JuliaLang/julia/issues/1974 and made an attempt to grok the issues involved.
Yes I have read most of the discussion , personally I like best mauro’s proposal
to fully promote getfield and to even allow additional arguments
getfield(x::MyType, ::Field{:foo}, args…)
for example in : A.size(1)
But the complex debate that went on afterwards convinced me to settle for less 
I was thinking of adding the following behavior to Core and to let multiple dispatch do its magic …
function setfield!{T}(value::Dict{Symbol,T},name::Symbol,x::T)::T
value[name] = x
end
function setfield!{T}(value::Dict{String,T},name::Symbol,x::T)::T
value["$(name)"] = x
end
maybe even limit that further
and force T to be of type Any so only general purpose dictionaries will have this privilege
The biggest problem, as @jeff.bezanson points out in that thread, is that we have to make sure that actual field access and module-qualified access to globals both remain predictably efficient. Introducing the ability to overload the syntax at all, makes that hard, no matter how limited use you make of the ability. That said, if you feel like taking a crack at implementing this and manage to do so without causing performance regressions, that would be excellent.
There are second order concerns about what effect such overloading would have on how people use the language, but that’s not a showstopper.
Sometimes a third-order concern (like breaking some subtle form of consistency) can be of greater importance in the long term.
Changing a widespread behavior (here accessing instance’s fields) of an operator (here the dot) on an existing type (here the built-in type Dict) would be unfortunate, as it would violate the “principle of least surprise” (and also make debugging harder). Doing so at the language level as a privilege for exceptional cases would be even worse (multiple dispatch is meant for specialization, not for hacking) and I’m glad that design decision makers in Julia (despite individual developers’ shortsightedness at the time) have generally resisted the temptation of adopting things promoted merely for their easiness/safety/convenience, while lacking strong justification (and especially early in the development).
The ability to overload something as basic as the dot operator is telling of a language’s power to give its programmers more freedom of choices (so it would be nice to have), but “with freedom comes responsibility”. Extending the language shouldn’t be breaking existing behavior, so in present topic’s case I vote for the usage of a separate operator.
My concern here would be having such behavior as a special case for a few inbuilt types. One of the most brilliant parts of Julia is how most the language is written in Julia itself, and is extensible via multiple dispatch. Wouldn’t having this a special case be a step backwards?
To me, not being able to overload getfield and setfield! actually came as a surprise. That said, I think in the end it may be best to stick with the current behavior to avoid performance problems and mysterious side effects. What would be useful is to standardize on a macro approach to the problem, as in the DotOverload.jl package, for example. I would like to see this functionality in Base, and refer to it in the documents about field access. The presence of the macro will alert the reader of the code to the fact that something non-standard is happening, and having the macro in Base makes sure everybody understands its purpose.
It is a surprise, but less of a surprise than a dot accessing an element (think of myarray.2) instead of a field. That’s the meaning of “least”, not to remove all surprises (of course the point of reference to label something as surprise is not someone’s past, but the language used, here Julia). If a language tried to remove all surprises, then it wouldn’t be surprisingly pleasant to use.
I started hacking away directly on the source code … I manage to get everything compiling and working.
How can do performance regression tests? is there a ready made script that performs that and outputs to some log file?
Thanks,
Tsur