Immutable Collections

[orenbenkiki]

This is a feature request.

I'm implementing a package where I have a container of arrays. This is meant to be used in a mult-threaded context, and tracking mutability/ummutability is very relevant.

I tried using ReadOnlyArrays and run into the issue JuliaArrays/ReadOnlyArrays.jl#2 where @bkamins made the point that Julia doesn't have a concept of immutable collections - this applies to Array, Dict, etc.

This seems like an unfortunate oversight. Tracking mutable vs. immutable collections is important for correct code in general, and even more so when dealing with multi-threaded code, which is becoming ever more relevant with today's multi-core hardware.

Granted that for quick-and-dirty scripts people should be able to to just hammer out some short piece of working code, without distractions from the language or the standard libraries. However, for more serious code bases it seems like it would make sense to at least provide an option to "freeze" a collection against further modifications - similarly to how type annotations are optional today.

As a precedence, Python provides a writeable flag in its Numpy ndarray type. The equivalent in Julia would be to add a few functions such as isfrozen, freeze!, unfreeze! to the standard collections API.

[KristofferC]

Ref #41777 and https://github.com/tkf/Mutabilities.jl

[orenbenkiki]

@KristofferC - thanks for the reference, I somehow missed it when I searched for the topic. Hope these catch on!

A point on doing this as a separate data type - I can see how this is attractive given Julia's multiple dispatch mechanism; however, this requires laboriously forwading every non-mutating function call involving the protected type. Consider for example the https://github.com/JuliaMatrices/ArrayLayouts.jl package; adding a new type for frozen arrays would require explicit support by that package to properly reports its memory layout.

Arguably the list of packages which would need to be extended would be small, and this might be the lesser evil (compared to mucking around with the internal representation of the collections to add an isfrozen flag).

Still, this is a concern - as long as the new immutable types are not part of the standard library, 3rd party libraries such as ArrayLayouts probably won't initially support them, which would reduce their acceptance by developers, which would reduce the motovation to support them in 3rd party packages...

To break this circle there should be sufficient committment to and promotion of the read-only package as "the" standard way to achieve this.

At any rate, closing this topic as it is under active work. Thanks again!