[swift-evolution] Immutable Structures

[Félix Cloutier]

If you're serious about your proposal, you need to come up with a realistic plan for phasing out the current struct semantics for everyone, in every use case that they have.

Félix

> Le 26 déc. 2015 à 11:14:44, Lino Rosa via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
> > "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/ <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 <mailto: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
> 
>  _______________________________________________
> 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/20151226/2c34639d/attachment.html>