Open Radar

 
Summary:
Arrays created with "let" should not allow their elements to change. Doing so breaks the principle of least surprise and is likely to cause bugs in concurrent code.

Steps to Reproduce:

1. Open an Xcode playground.
2. Type the following:

        let array = ["a"]
        array[0] = "b"

Expected Results:
A "Cannot assign to the result of this expression" error.

Actual Results:
The array is mutated.

Comments:
I understand that Swift can perform optimizations on semi-mutable arrays that it can't perform on fully mutable ones. That's great! I want you to perform those optimizations where you can!

But that doesn't mean you should overload "let"—which for all other struct types means "this is immutable"—to indicate an array is semi-mutable. When I pass an immutable array to another function—or, God forbid, to a block on another queue—I need to be able to trust that the array won't change behind my back. Sure, I can call unshare() defensively, but then what's the point of having the optimization at all?

It'd be much better to create a FixedArray type or use a different keyword to indicate when you actually want this optimization. As it is, I'm likely to stick with NSArray—and that's a damn shame. I want Swift.Array's type safety, but not at the cost of creating async bugs.