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