Is this a bug in @Published?

Using Swift
5

The total output is:

closure value: 0
object value: 0

closure value: 42
object value: 0

closure value: 14
object value: 42

So yeah, the value is being published in willSet before it's set. But even then, this feels wrong. @Tony_Parker any input? Is this expected behavior?

1 Like
6

Looks like a will set to me, but I‘m not sure if that‘s expected behavior here.

7

Actually that should be unrelated. IIRC Published always emitted the latest value through its publisher.

You can imagine the internals to be more like this:

set {
  // will set
  outerSelf.objectWillChange.send()
  // did set that pushes the value through the publisher
  outerSelf[keyPath: wrapperKeyPath].storage = newValue
}
8

Hmm, it's weird that it's not documented.

1 Like
9

The Combine book says:

“Whenever you modify the value of age, $age will emit that new value.”

10

It does seem to lean toward post-modification, but could be the way it's phrased.

11

But the question is, where it's emitted, if you access the value itself, will it be the same as the emitted value? (According to the example above, no.) If not, should it be?

12

That is a fair question, but it would be strange to call this a didSet while the publisher fires before the property is truly set.

Can you emit on main queue and see if that changes anything?

13

I don't know anything about Combine, but this creates an infinite loop which is... fun..

let s = t.valuePublisher.sink { value in
	print("closure value: \(value)")
	print("object value: \(t.value)")
	t.value = value
}
14

As it should :sweat_smile:

15

That is expected, it‘s like if you mutate a property during didSet observer. (Not sure if the compiler allows it though.)

16

Ah and sorry for confusion, I had closure and object values flipped in my head. However my previous statement about a didSet event remains.

17

That actually does resolve the issue (I can't control what queue @Published publishes on, but I can control what I receive on):

This change:

var valuePublisher: AnyPublisher<Int, Never> {
    $value.receive(on: DispatchQueue.main).eraseToAnyPublisher()
}

Produces:

closure value: 42
object value: 42

But it drops the initial value which is likely due to the causes outlined in Combine `.receive(on: RunLoop.main)` loses sent value. How can I make it work? - #40 by somu

18

But now I'm curious because I'm struggling to understand why receiving on the main queue would alter that behavior? I think I need to re-read that thread.

19

Are you testing it with a beta device like mentioned in the thread? If not then it works because internally it still uses async which causes the publisher to emit after the property is truly set. However this is still not didSet semantic.

20

:man_facepalming:t2: I'm not

I'll have to install 10.15.2 beta 3 on a volume and test again. (I assume that beta is included in the list of "associated releases"?)

If anyone else is curious, has the beta installed, and wouldn't mind — will you run the original code in the first post and post the output?

21

Following was tested on :
Xcode Version: 11.3 beta (11C24b)
macOS version: 10.15.1 (19B88)
Platform: iOS Playground

Case 1 - not on main thread:

Code:

let s = t.valuePublisher
    .sink { value in
    print("closure value: \(value)")
    print("object value: \(t.value)")
}

t.value = 42
t.value = 14

Output:

closure value: 0
object value: 0
closure value: 42
object value: 0
closure value: 14
object value: 42

Case 2 - RunLoop.main:

Code:

let s = t.valuePublisher
    .receive(on: RunLoop.main)
    .sink { value in
    print("closure value: \(value)")
    print("object value: \(t.value)")
}

t.value = 42
t.value = 14

Output:

closure value: 0
object value: 14
closure value: 42
object value: 14
closure value: 14
object value: 14
1 Like
22

Which OS do you target in Playground? If it‘s macOS then you also need latest Catalina beta as the framework is part of the OS. On the other hand if it‘s iOS then it should use the framework version from the sim that would have the new behavior.

The last output is completely unexpected. :exploding_head:
Can you also try DispatchQueue.main as the scheduler?

23

I am a newbie ... I am not sure if I am messing something up.

macOS version: 10.15.1 (19B88)
Platform: iOS Playground

Case 3: DispatchQueue.main

Code:

let s = t.valuePublisher
    .receive(on: DispatchQueue.main)
    .sink { value in
    print("closure value: \(value)")
    print("object value: \(t.value)")
}

t.value = 42
t.value = 14

Output:

closure value: 0
object value: 14
closure value: 42
object value: 14
closure value: 14
object value: 14
1 Like
24

I'd say it's quit expected. The events are rescheduled to the future (next runloop), after the last line execute.

It will be easier to understand:

let s = t.valuePublisher
    .receive(on: RunLoop.main)
    .sink { value in
    print("closure value: \(value)")
    print("object value: \(t.value)")
}

t.value = 42
print("set value to 42")
t.value = 14
print("set value to 14")

Output:

set value to 42
set value to 14
// next runloop, perform queued tasks one by one
closure value: 0
object value: 14
closure value: 42
object value: 14
closure value: 14
object value: 14