> On Jul 24, 2017, at 2:38 AM, somu subscribe via swift-users > <swift-users@swift.org> wrote: > > Thank a lot Quinn, your solution to use inout works well without crashing. > > Question 1: > - Also changing Helper to a class doesn’t seem to crash. Is that a solution > that wouldn’t cause a crash or just works by chance ?
It is not by chance. It illustrates the key difference between classes and structs: class instances are passed by reference because they have identity. The identity of an object never mutates: If you change `Helper` to a class, then you can also change `helper` property from `var` to `let` and still change the value of `v1` inside `helper`. If this is not clear to you, I recommend you first get a better understanding of differences between value types and reference types and especially learn about object aliasing before deciding which approach is the right approach for you. > > > Background: > Just a little background into what I was trying to achieve (I could be wrong): > > - I have a set of classes C1, C2, C3 which has a lot of common code > > - I would like to build something that can be reused without exposing the > implementation details. (I can subclass but would expose the underlying > functions, same applies to protocol as well) > > - I thought I would build helper class / struct which would contain the > common code. I can make the helper a private property so that the functions > wouldn’t be exposed to the instances of C1, C2, C3. In order to achieve that > I had to pass some functions from C1 into the Helper struct. > > Question 2: > - Is this problem (hiding implementation details) normally tackled using > Helper class (or struct) or is there a more better approach ? It depends on what you mean by hiding and whether those classes sharing common implementation details also share a common public API (protocol) or ancestry (shared superclass). Generally, what you call `Helper` is the correct way to go if the following is true: Your `Helper` makes logical sense as something coherent with its own meaningful properties, so that it can be given a specific name that makes sense (besides a very broad name such as your example `Helper`). > > Thanks and regards, > Muthu > > >> On 24 Jul 2017, at 4:14 PM, Quinn The Eskimo! via swift-users >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >> >> >> On 24 Jul 2017, at 07:04, somu subscribe via swift-users >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >> >>> - Is there a bug in my code which is being detected in Xcode 9 ? >> >> Yes. The problem here is that `doSomething(f1:)` is a mutating function, so >> it acts like it takes an `inout` reference to `self.helper`. That’s one >> mutable reference. It then calls `Car.f1()`, which tries to get a >> non-mutating reference to exactly the same struct. This is outlawed in >> Swift 4 as part of the memory ownership effort. >> >> You can read more about the specific change in SE-0176 “Enforce Exclusive >> Access to Memory”. >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md>> >> >> And the general background to this in the “Ownership Manifesto" >> >> <https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md >> <https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md>> >> >>> If so could you please explain and suggest an alternate approach / fix ? >> >> It’s hard to offer concrete suggestions without knowing more about your >> high-level goals. One option is for `doSomething(f1:)` to pass the `inout` >> reference through to `f1`. For example: >> >> mutating func doSomething(f1: (inout Helper) -> ()) { >> f1(&self) >> } >> >> func f1(h: inout Helper) { >> _ = h.v1 // no crash >> } >> >> but whether that makes sense in your code is for you to decide. >> >> Share and Enjoy >> -- >> Quinn "The Eskimo!" <http://www.apple.com/developer/ >> <http://www.apple.com/developer/>> >> Apple Developer Relations, Developer Technical Support, Core OS/Hardware >> >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
