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 > <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
