Given that the Swift team has already said they aren't going to change the programming model, I don't think further conversation belongs on swift-evolution, to be honest.
Austin > On Dec 26, 2015, at 8:50 AM, Félix Cloutier via swift-evolution > <[email protected]> wrote: > > 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] <mailto:[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] <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
