[swift-evolution] Immutable Structures

[Paul Cantrell]

Structs behave _as if_ they are immutable and every mutation creates a copy.

The compiler may — and usually does — optimize this away as a direct mutation. (And then there’s inout, which is tricky.)

It’s a brilliant model, and I believe a strong one as it stands. Lino, I believe this addresses your #1 and #3. I’m afraid I don’t follow your #2. Can you elaborate?

Cheers, P


> On Dec 23, 2015, at 10:15 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> No, this is a consequence of structures being passed by value to property accessors. The getter doesn't return a reference to the frame, it returns a copy of it, so it is accompanied by a hidden set operation where it replaces the whole thing.
> 
> Félix
> 
>> Le 23 déc. 2015 à 11:09:43, Kevin Lundberg via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> I believe Ian is correct in that changing any struct's value in any way creates a whole new struct.
>> See http://swiftstub.com/635749345 <http://swiftstub.com/635749345> for proof (the didSet property observer fires every time a change happens to the struct).
>> 
>>> On Dec 23, 2015, at 11:00 AM, Lino Rosa via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Reassigning structures will create new ones. Mutating functions and reassigning its properties won't: they mutate it.
>>> On Wed, Dec 23, 2015 at 10:51 AM Ian Ynda-Hummel <ianynda at gmail.com <mailto:ianynda at gmail.com>> wrote:
>>> I thought structures were immutable and mutating functions actually just created new structures, thus maintaining the by value semantics.
>>> On Wed, Dec 23, 2015 at 10:45 AM Lino Rosa via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> I believe the language would be improved by making structures immutable.
>>> 
>>> 1) The choice between classes and structures isn’t clear right now. If structures were immutable it would be natural to use them as value objects.
>>> 
>>> 2) Refactoring a mutable structure into a class when it’s being passed around multiple threads removes the by-value semantics seamlessly. The resulting mutable class isn’t thread-safe.
>>> 
>>> 2.1) Even when passed around a single thread, the resulting class would be passed by reference, so any mutations would have unintended consequences.
>>> 
>>> 3) We could probably remove some syntax: `mutating` keyword and variable parameters. Also the `var` keyword before a structure could be used to denote reassignment (not mutability), just as it does with classes.
>>> 
>>> Of corse I might not be seeing the whole picture, so please weigh in.
>>>  _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>  _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/4d329ee2/attachment.html>