Willicious-k
(SungJong Will Kim)
1
I've ran into an error message while writing some combine code.
"Using 'super' in a closure where 'self' is explicitly captured is not yet supported"
Here's reproduced code snippet image:
import UIKit
import Combine
class SomeParentObject {
func openFunction() {
print("parentFunction")
}
}
final class SomeChildObject: SomeParentObject {
var cancelBag = Set<AnyCancellable>()
override func openFunction() {
print("childFunction")
}
func bind() {
Just("hello")
.sink(receiveValue: { [weak self] _ in
super.openFunction() // ERROR: "Using 'super' in a closure where 'self' is explicitly captured is not yet supported"
})
.store(in: &cancelBag)
}
}
I tried to find articles about this error, but I couldn't find one explaining why.
I wonder why such restriction was introduced in Swift.
Could anyone give me an explanation?
Thanks in advance.
Avi
2
You're getting the error because you capture self weakly. Remove [weak self] and it will compile and give the expected results.
I do not know why capturing weakly breaks this.
bbrk24
3
If you need to do this particular combination of things, this should suffice for a workaround:
final class SomeChildObject: SomeParentObject {
var cancelBag = Set<AnyCancellable>()
override func openFunction() {
print("childFunction")
}
private func superOpenFunction() {
super.openFunction()
}
func bind() {
Just("hello")
.sink(receiveValue: { [weak self] _ in
self?.superOpenFunction()
})
.store(in: &cancelBag)
}
}
There's no deep fundamental reason why it has to be prohibited; It's an implementation limitation. Fixing it is a matter of ensuring that SuperExpr can represent this in the AST, and then possibly adjusting SILGen's lowering of super calls to take this possibility into account. It's doable without a huge effort; it's just one of those edge cases that hasn't been a priority yet.
2 Likes