Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-5442] Calling subscript setter with a WritableKeyPath results in wrong invocation order of embedded setters #48016

Closed
swift-ci opened this issue Jul 12, 2017 · 8 comments
Closed

[SR-5442] Calling subscript setter with a WritableKeyPath results in wrong invocation order of embedded setters #48016

swift-ci opened this issue Jul 12, 2017 · 8 comments
Assignees
@jckarter
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-5442
Radar rdar://problem/33267959
Original Reporter templar (JIRA User)
Type Bug
Status Closed
Resolution Done
Environment

Xcode Version 9.0 beta 3 (9M174d) shipped version, macOS 10.12.5

Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee @jckarter
Priority Medium

md5: e51a826a4abdfa985a823dcc301f27d4

relates to:

  • SR-7709 didSet values are incorrect when using KeyPaths

Issue Description:

WritableKeyPath mutation behavior totally differs from traditional property setter

struct Core {
    var val = 0 {
        didSet {
            print("Core.val setted: \(val)")
        }
    }
}

struct Wrapper {
    var core = Core() {
        didSet {
            print("Wrapper.core setted: \(core.val)")
        }
    }
}


var obj1 = Wrapper()
obj1.core.val = 1
print("---")
var obj2 = Wrapper()
let keyPath = \Wrapper.core.val
obj2[keyPath: keyPath] = 1

output:

Core.val setted: 1
Wrapper.core setted: 1

Wrapper.core setted: 0
Core.val setted: 1
@jckarter
Copy link
Member

@swift-ci create

@jckarter
Copy link
Member

PR for master: #10913

@jckarter
Copy link
Member

PR for 4.0: #10915

@DougGregor
Copy link
Member

ab3e662

@swift-ci
Copy link
Collaborator Author

Comment by Daniel Williams (JIRA)

I'm still seeing this issue with the following code - perhaps the extra level of indirection from the protocol, or the class-with-struct semantics are causing it?

https://gist.github.com/dawilliams-gpsw/0f057637cfef3e9c9889af5a6beb1355

print out:

old value: ConcreteConfig(someVal: "some other original val")
new value: ConcreteConfig(someVal: "some other original val")
someval is now this is a new value!

-------

someval is now this is a new value!
old value: ConcreteConfig(someVal: "some other original val")
new value: ConcreteConfig(someVal: "this is a new value!")

cc @DougGregor

@swift-ci
Copy link
Collaborator Author

Comment by Daniel Williams (JIRA)

Also of mention, shouldn't the `oldValue` from the second call reflect the changed value from the first call?

@jckarter
Copy link
Member

xcadaverx (JIRA User) You're right that the behavior should be the same, though that looks like a different albeit similar problem. Mind filing a new bug?

@swift-ci
Copy link
Collaborator Author

Comment by Daniel Williams (JIRA)

@jckarter - no problem. I've linked it to this ticket since both are similar.

new bug:

https://bugs.swift.org/browse/SR-7709

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jckarter jckarter

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jckarter @DougGregor @swift-ci