[swift-users] Simultaneous accesses, but modification requires exclusive access

[somu subscribe]

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 <hooman at mac.com> wrote:
> 
>> 
>> On Jul 24, 2017, at 2:38 AM, somu subscribe via swift-users <swift-users at swift.org <mailto:swift-users at 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 at swift.org <mailto:swift-users at swift.org>> wrote:
>>> 
>>> 
>>> On 24 Jul 2017, at 07:04, somu subscribe via swift-users <swift-users at swift.org <mailto:swift-users at 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 at swift.org <mailto:swift-users at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org <mailto:swift-users at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170731/6b175658/attachment.html>