[swift-evolution] Immutable Structures

[Lino Rosa]

> "1) Its not true. Its just about the reassignment. But for value-types in
automatic the process of copy-change and assign."

I understand that, but semantically it sure looks like it's true. It's an
implementation detail, all about the copy-on-write optimization right? Why
should the developer have to know about that?

> "2) because only value types need this keyword"
> "3) what's the problem here?"

Consistency. Makes the language harder to explain. To me the `mutating`
keyword should either be used in classes as well or not used at all. Both
would simplify things. But this is running off-topic from the original post
though.

> "Can you elaborate this? Does not appear a real world problem."

Not a specific example, but every line like `something.a = "anotherValue"`
might or might not be relying on value semantics. After refactoring, the
developer would have no choice but to read every line with `something` and
judge whether value semantics was assumed or it was irrelevant. Really
error prone. Any mistake would result in unintended reference sharing, race
conditions etc. The actual bug might surface far from the originating issue.

> "hu?  Just check if the type is a struct or a enum! So will be a value
type. Whats the problem here?"

Of course, but you'd have to pause reading and jump to the definition each
time. And keep two mental models when structures and classes are used
together.

> "No, the whole point of structs are not to be used in small and simple
cases, not on Swift, in swift um Swift are first class citizen and can be
use for complex data structure, like Array and Strings. You can make a
private shared buffer behind the scenes."

It does certainly seem to be this way in practice. It was the impression I
got from Swift's official docs: "*The structure’s primary purpose is to
encapsulate a few relatively simple data values.". *But now I realize it
talks about other possible use cases.

> "Try this one: https://developer.apple.com/videos/play/wwdc2015-408/ ( Protocol-Oriented
Programming in Swift )"

I enjoyed this one, but it's about inheritance vs. protocols. He changes
classes to structures because he thinks it fits the model but he could have
kept classes and still proved his point that protocols are more powerful
and flexible.

I called my attention though, at around 25:20m he shows
`diagram.elements.append(diagram)` and says:* "**Now, it took me a second
to realize why Drawing wasn't going into an infinite recursion at this
point"*. That's kind of my point, these little surprises sprinkled around
the code.

Brent Royal-Gordon:

> "In a regular method, `self` is a regular (constant) parameter, but in a
`mutating` method, `self` is `inout` so that it can be mutated and those
mutations will reach the caller's copy of the instance. There's no need for
an `inout` `self` on reference types, because the mutations are performed
on the shared instance which both the caller and callee have a reference
to, so `mutating` only really makes sense for value types."

But the `mutating` keyword isn't really needed to make `self` work this way
for structures. It's actually not strictly needed at all. Another thing the
`mutating` keyword "allows" is for the method to be able to reassign
properties. I was advocating that `mutating` had only that meaning in order
to be more consistent. Then it would be equally useful for classes to make
APIs more clear with respect to mutation.


On Fri, Dec 25, 2015 at 7:16 PM Brent Royal-Gordon <brent at architechies.com>
wrote:

> > However I could probably still agree with you if mutating was also used
> in classes. What's the point of having it only on structures?
>
> In a regular method, `self` is a regular (constant) parameter, but in a
> `mutating` method, `self` is `inout` so that it can be mutated and those
> mutations will reach the caller's copy of the instance. There's no need for
> an `inout` `self` on reference types, because the mutations are performed
> on the shared instance which both the caller and callee have a reference
> to, so `mutating` only really makes sense for value types.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151226/9eae652b/attachment.html>