Thanks a lot Hooman, I understand better now. The part that tripped me was the fact that value types would be copied every time.
I didn’t realise I wasn’t making a copy of the value type in my program, the same instance of the value type was getting passed (as Quinn and you had pointed out). Thanks and regards, Muthu > On 31 Jul 2017, at 4:27 AM, Hooman Mehr <hoo...@mac.com> wrote: > >> >> On Jul 24, 2017, at 2:38 AM, somu subscribe via swift-users >> <swift-users@swift.org <mailto: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 >>> <https://lists.swift.org/mailman/listinfo/swift-users> >> >> _______________________________________________ >> 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
