[swift-evolution] Immutable Structures

Lino Rosa lino.aguiar.rosa at gmail.com
Wed Dec 23 10:37:58 CST 2015


Félix Cloutier*: *Yes immutable structures would look just like read-only
classes, but I don't think this makes the choice more ambiguous. The use of
structures could be encouraged whenever possible with a clear message: "Is
it all immutable? Use structures then". Perhaps even be explicit on the
performance implications of stack storage. I believe the real problem is C
interop, and for that I have no arguments.

Paul Cantrell: Sure, example below. Changing `struct Position` into `class
Position` would still compile and print 30 instead.

==============================
struct Position {
  var x: Int
  var y: Int

  init(x: Int, y: Int) {
    self.x = x
    self.y = y
  }
}

func move(var position: Position) {
  position.x += 20
}

var p1 = Position(x: 10, y: 10)
move(p1)

print(p1.x) // prints 10
==============================

On Wed, Dec 23, 2015 at 11:24 AM Paul Cantrell <cantrell at pobox.com> wrote:

> 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> 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 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> 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>
> 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> 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
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/aee80c5d/attachment.html>


More information about the swift-evolution mailing list