I’m pretty concerned that struct-based arrays or dictionaries are considered a permanent limitation, since both are completely fundamental to the correct behavior of Swift algorithms.
Minimally there should be some sort of pre-processor or compiler flag to enable struct behavior for arrays and dictionaries. It seems possible to get good performance on arrays and dictionaries that are “immutable” with copy-on-write-like semantics using a technique similar to the one employed by facebook’s immutability-js.
There’s a big movement within the swift community to transition to value-oriented and functional style programming. If the basic building blocks, arrays and dictionaries, don’t honor basic assumptions then Silver stops being viable for most shops. Some people will completely lose trust in the idea that it just works.
I’m just throwing stuff against the wall here, but how can we quickly enable a work-around? Is there at least a compiler hook where I can switch in a immutability-js-like implementation for arrays and dictionaries so that all my code that depends on that assumption won’t break?
The main problem is that struts with copy-on-write semantics that work reliably are not doable on .NET (and possibly Java). And arrays and dicts without copy-on-write would be unusably slow. We don’t like this limitation either, but I,me afraid there’s no way around this for now.
Note that array and dictionary are implemented purely in code, in the Swift Base Library. They are not a feature of the core compiler. So in theorylnour current implementations could be switched over to a struct-based one at any time, simply by changing the library. IOW, if someone values struct-ness over performance, they could link in their own array type.
The compiler simply maps [T] and [T:U] to whatever Swift.Array and Swift.Dictionary type it finds referenced.