Andy Ferris

Yes, it's definitely something we should look at here. What really needs to happen is to come up with a cohesive plan for multi-dimensional dictionaries. Sometimes the indices are Cartesian...

Yes, exactly. Except I’m imagining precisely three “factories”: 1. Keys and values given - `new` (Or whatever) 2. Keys given but values `undef`, to be filled in afterwards - `similar`...

Yeah. My thoughts are: When you NEED certain traits then you are going to have to use less generic code. The fact is that there is _always_ more traits to...

The operation is a bit like `collect(T, values)`. Except the `T` is a container you want to be similar to, not the element type, and it's a value. Perhaps `collect_similar(old_container,...

Arrays are interesting. The keys are sometimes unnecessary, right? Though you might want something for offset arrays. And higher dimensional arrays. And static arrays (the sizes are specified in `similar_type`...

> Could well be true. I guess I don't have a strong opinion one way or another about this. Yeah, me neither. It just seemed like immutable container support was...

I guess this was a bit of an experiment in a value-driven interface. Traits functions that take values and return values. Also, it's theoretically possible to have types that are...

> Also, it's theoretically possible to have types that are "freezable" at run-time, for example. For context, copy-on-write indices would work well with indices and how `similar` doesn't copy them....

Did you guys have any further thoughts? Are you aware of some good scenarios for defining and/or using it at the type level?

Yes, that's right - the order of the elements in a *Dictionaries.jl* dictionary is now an important feature. Take for example `==`. ```julia julia> d1 = Dictionary(["a", "b"], [1, 2])...