In Swift arrays, dictionaries and strings are structures with value-semantics. As to why, well, to quote the Swift language reference manual: "One of the primary reasons to choose value types over reference types is the ability to more easily reason about your code. If you always get a unique, copied instance, you can trust that no other part of your app is changing the data under the covers. "
Behind the scenes, however, structures (including strings) are passed by pointer. Swift then uses copy on write so
What if you pass a string to a function, and a different thread then changes the original string? Does that also copy on write? Or does the function suddenly see the string change?
(Thread A and thread B both have access to the same string S, B passes S to function F, function F reads S, thread A changes S, function F reads S again)
Structurally, you have to jump through hoops to explicitly see that mutation occur (using types that don't support copy-on-write, aka not String). So answering your question, structurally, you're rarely mutating the string in place, unless the code can be certain that it's uniquely referenced. Since you aren't mutating in place, any other threads with a reference, end up still pointing at the static previous data.
In your example: thread A wouldn't successfully change S. instead, it would create S-prime, and thread B would still be pointing at S.
In the code though, thread A can have syntactically nice methods that look like they're mutating, but they only actually mutate the same memory, if it's uniquely referenced. If it's not uniquely referenced, the underlying system performs the copy-on-write, before then mutating the new, uniquely referenced object.
Why are strings passed by value? (Score:4, Interesting)
Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?
Re: (Score:5, Informative)
In Swift arrays, dictionaries and strings are structures with value-semantics. As to why, well, to quote the Swift language reference manual: "One of the primary reasons to choose value types over reference types is the ability to more easily reason about your code. If you always get a unique, copied instance, you can trust that no other part of your app is changing the data under the covers. "
Behind the scenes, however, structures (including strings) are passed by pointer. Swift then uses copy on write so
Re: (Score:2)
What if you pass a string to a function, and a different thread then changes the original string? Does that also copy on write? Or does the function suddenly see the string change?
(Thread A and thread B both have access to the same string S, B passes S to function F, function F reads S, thread A changes S, function F reads S again)
Re:Why are strings passed by value? (Score:2)
Structurally, you have to jump through hoops to explicitly see that mutation occur (using types that don't support copy-on-write, aka not String). So answering your question, structurally, you're rarely mutating the string in place, unless the code can be certain that it's uniquely referenced. Since you aren't mutating in place, any other threads with a reference, end up still pointing at the static previous data.
In your example: thread A wouldn't successfully change S. instead, it would create S-prime, and thread B would still be pointing at S.
In the code though, thread A can have syntactically nice methods that look like they're mutating, but they only actually mutate the same memory, if it's uniquely referenced. If it's not uniquely referenced, the underlying system performs the copy-on-write, before then mutating the new, uniquely referenced object.