How to construct an empty AbstractDictionary given the Dictionary Type?

[schlichtanders]

Hi, sorry if this question is somehow inbetween an discourse question and an issue/feature request.

Is it possible to create a an empty AbstractDictionary given the concrete type of the system? I am asking because it seems within AbstractDictionaries/AbstractDict it is especially common to have totally different kind of constructors which hence do not provide a common interface.

I see that I can construct empty AbstractDictionary, given an instance, but I wasn't able to find one which takes the type instead.

[andyferris]

I have only recently started to formalize this with empty_type. This is the current set of "rules":

1. Dictionaries that are isinsertable have a zero-argument constructor. E.g. Dictionary{String, Float64}().
2. Dictionaries that are issettable have have an undef constructor like Dictionary{String, Float64}(new_indices, undef).
3. Dictionaries designed to store data (including the above two, or even immutable dictionaries, but not the wrapper-like dictionaries returned from view, filterview, reverse, etc) would have a two argument constructor like Dictionary{String, Float64}(new_indices, new_values). There would generally be a one-argument constructor Dictionary{String, Float64}(from) which is just sugar for Dictionary{String, Float64}(keys(from), values(from)). The values() is there to support Dict, but otherwise it's an identity function.

When you have a new keytype or eltype that you want to use, there are helper functions. Insertable dictionaries can be created by empty and you can discover their types via Dictionaries.empty_type and call the zero-argument constructor from that. Settable dictionaries can be created by similar and I'd like to introduce a similar_type function. We also need a type-domain function for 3 above, for when you already know the keys and the values; I don't have a good name for that (for reference, this would be the functional equivalent of StaticArrays.similar_type which was designed around immutable arrays).

Does that help? I'd like to finish this and write it all up at some point.

[schlichtanders]

yes that helps - I think for my usecase it is fine to fallback to zero-argument constructor for now.

Looking forward to the whole type interfaces!