Support dict.field syntax for Dict{Symbol, <:Any}

[oschulz]

It would be very convenient to be able to use d.foo with a d = Dict(:foo => ...).

Obviously, this would require defining methods of Base.getproperty, Base.setproperty! and Base.propertynames for Dict{Symbol, <:Any} in Base, which I guess would count as a breaking change. But now that #25311 is merged, it sure would be fun to have in. :-)

[oschulz]

Question is, would we want this only for Dict{Symbol, <:Any}, or for Dict in general, to support dictionaries with mixed key types (I guess only the keys of type Symbol would be used in that case)?

[StefanKarpinski]

I think just defining it for all dicts would make sense with d.foo being equivalent to d[:foo]. Of course, it would only work for dictionaries where d[:foo] works. This would force access to the internals of dictionaries via getfield but that's ok since poking around at dictionary internals is not the best idea anyway.

[KristofferC]

d."foo" would work.

[StefanKarpinski]

True, and that would be nice syntax as well.

[yuyichao]

👎 Seems like a good step to be closer to javascript.

Also this will cause a deviation between API of Dict and other similar types or make it extremely hard for users to implement them if they want to provide a similar API as the base one.

[JeffBezanson]

I'm also mostly against this; I think it just starts to be too many ways to do the same thing.

[oschulz]

@JeffBezanson> I'm also mostly against this; I think it just starts to be too many ways to do the same thing.

Maybe. But on the other hand, it might be very powerful when writing generic code. I see Dict{Symbol} as the natural dynamic equivalent of struct and NamedTuple, and with this syntax the same code would work for all of them. Of course that doesn't mean people should start to use Dict instead of struct/NamedTuple.

@yuyichao> Seems like a good step to be closer to javascript.

True - but in certain uses cases, that may be a good thing. Even a high-speed Julia application may have to deal with nested dicts in a a low-speed corner (configuration data, JSON, ...), and the code will look much nicer without a flood of square brackets. Besides, we already have getproperty & friends, using them for Dict seems natural to me.

[davidavdav]

A while ago there was a discussion about using a character like $ to resemble . syntax, but with meaning a$b = a[:b], i.e., a getindex(), which would be handy for objects of type Dict and DataArray, and perhaps also drilling down Python objects in PyCall.

In fact, I worked hard to get the then-current meaning of $ as \xor operator deprecated and replaced by ⊻ in #18977, so that this character could be used for such a purpose in the future. The PR was merged about a year ago.

Now the discussions in #1974 c.s. have finally led to the implementation of getproperty. I've played around a bit with it, and indeed you can say

Base.getproperty(d::Dict, s::Symbol) = s ∈ fieldnames(Dict) ? getfield(d, s) : getindex(d, s)
d = Dict(:wallet =>1, :keys => 2)
@show d.wallet
@show d.keys

with perhaps somewhat unexpected result in the last line.

For that reason I would still consider it an option to use syntax a$b as a shortcut for getindex(a, :b)or similar---in the end, we've played $ free for such use, it resembles R syntax, and it allows proper separation between struct fields and index access.

This would first require full deprecation of $ as \xor in julia 0.7 (for which it is about time, I suppose, anyway) and different parsing.

[yuyichao]

@oschulz FYI, you've completely missed the main objection in my comment. And,

it might be very powerful when writing generic code. I see Dict{Symbol} as the natural dynamic equivalent of struct and NamedTuple, and with this syntax the same code would work for all of them.

A little bit for NamedTuple and not at all for struct and in anycase Dict are much more closer to AbstractDict and I'll claim it is completely impractical to require all of those to provide the same API so doing this will hurt generic code. Unless you are going to throw in random types to replace the Dict, defining a getindex on the type you want to replace the Dict with is trivial Base.getindex(a::AbstractConfig, key::Symbol) = getfield(a, key) if for whatever reason you don't want to just use NamedTuple.

the code will look much nicer without a flood of square brackets

Disagree completely. For one, loading unknown configure dict into Symbol is already a bad thing, String should have been used instead. a[:b] and a["b"] are also only two characters longer than a.b and a."b" so for any key/variable name of non-trivial length they don't shorten your code by much. Finally, assuming playing with Dict is not the only thing you do in your code, indexing with string or symbol keys makes it very consistent with other operations on the Dict without a known constant key and distinct from normal field access used in other part of the code. With getproperty on Dict you are just hiding the fact that you are indeed doing a dict lookup.

Besides, we already have getproperty & friends, using them for Dict seems natural to me.

No, getproperty is a feature that can be easily abused. Using it for everything does not make sense.

[oschulz]

@yuyichao > FYI, you've completely missed the main objection in my comment.

No, I didn't - I just didn't have a good response to your argument regarding the API of Dict and other similar types. ;-) I thought about doing this for Dict only, not for similar types as well, but you can judge those implications better than I can.

[oschulz]

@yuyichao > For one, loading unknown configure dict into Symbol is already a bad thing

I won't argue here, but I'd like to learn why. Wouldn't Symbol be a natural choice if terms repeat frequently? Or is it bad to risk "flooding" the Symbols table?

[yuyichao]

missed the main objection

I just mean that you didn't reply to them at all, together with most of the objections in #25750 (comment)

Wouldn't Symbol be a natural choice if terms repeat frequently? Or is it bad to risk "flooding" the Symbols table?

If by whatever mean, you are confident that the keys are always known to be within a fixed set it's fine but that's not generally a property you can rely on when loading configure file. Allocating a symbol table entry for "a"^1000_000 that cannot be freed without a restart is pretty bad.

[StefanKarpinski]

Honestly, this is one of the features of languages like JavaScript and K that people who use those languages really love, and one that I've personally wanted to be able to emulate for a long time. So what if it's two ways to write the same thing? When has that ever been such a huge problem? If we don't add support for this to Dict people are just going to create a SymDicts package that defines a SymDict type that wraps a Dict with this feature. Sure, you can say, "great, let them create that package" but why relegate it to package?

[davidavdav]

If strings are better as keys for config.json style objects than symbols, because they don't flood the symbol table, then that should be their representation. But still, being able to access an object in code using syntactic sugar like config.params.training.init.nepochs rather than config["params"]["training"]["init"]["nepochs"] is arguably easier to read, and could be supported by a (local) definition

Base.getproperty(d::Dict{<:AbstractString,<:Any}, s::Symbol) = s ∈ fieldnames(Dict) ? getfield(d, s) : getindex(d, string(s))

In order not to confuse people with the getfield interpretation of ., this could alternatively be written config$params$training$init$nepochs if $ receives that meaning...

[vtjnash]

So what if it's two ways to write the same thing

It's great for the consumer, but expands the API for the implementer, so the wrapper approach may actually be more reliable and easier to code (SymDicts can wrap any AbstractDict with String keys, and since it only has one field and a small API, it's easier to write getfield(d, :dict) everywhere in its implementation. This might be much easier if we re-design many of our uses of the internal top lowering to be module-specific globals as suggested in #22147, or alternatively had just merged that PR (as either would make it easy to make a module-internal getproperty function that called getfield for the Dict implementation code, but exported a different definition for Base.getproperty)

Allocating a symbol table entry for "a"^1000_000 that cannot be freed without a restart is pretty bad

As davidavdav, this isn't a fundamental issue, the code just needs to distinguish between the keys (as Strings) and the syntactic getproperty calls (as Symbols).