The "stylistic argument" that was discussed was the idea that if the method or accessor resolved - that is, the weak property was indeed non-nil, and therefore the execution continued, then within that access you could assume that the object was itself non-nil due to fact it would not have gotten to that stage otherwise.
The example people used and I believe the ultimate intent of the discussion was people trying to force their closures to be single line and avoid a guard let self = self..., eg:
dismissViewController(animated: true) { [weak self] in
self?.delegate?.object(self!, didUpdateState: self!.state)
}
This would avoid the separate guard statement:
dismissViewController(animated: true) { [weak self] in
guard let self = self else { return }
self.delegate?.object(self, didUpdateState: self.state)
}
The discussion was that this was needlessly messy considering that the compiler did enforce the order of operations to ensure the safety of the access. (which I’m now aware it doesn’t)
I couldn't find any references online to how Swift officially handles this and whether there was indeed a rule guiding compiler development to avoid this ever being accidentally "broken" in the future.
Personally I prefer to resolve optionals explicitly wherever possible, but I thought understanding the order of operations and guarantees was worth a little investigation.