<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’ll leave it to others to explain whether this is the intended behavior, but the further I get from properties being idempotent, the more grief I’ve had. Especially when (as I assume is your real use case) I tried to assign something to itself to force a didSet {} during viewDidLoad(). </div><div class=""><br class=""></div><div class="">If I may read your mind further: Yes, your prepareForSegues will fill view controllers’ state before the view is instantiated, and therefore before its UI can be made to conform. Give in: Have the setter store the value in a private temporary, attempt to update its UI element through a conditional chain from its outlet (a no-op if the outlet isn’t filled yet), and have viewDidLoad() call a batch vars-to-UI func to bring everything up to the current state.</div><div class=""><br class=""></div><div class="">Of course there are side-effects; that’s what didSet {} is for. But assignment-to-self is more apt to be a typo for some other assignment than not; and it’s easy to work around by factoring the side effects into their own func — and then you can replace the self-assignment with an explicit call to the service you wanted to accomplish. Giving that service a name isolates it from additional tasks you might want to do at didSet {} time, and makes it clear at the point-of-call exactly what you want to do.</div><div class=""><br class=""></div><div class="">I can <i class="">imagine</i> an optimizer or runtime that assumes an assignment that doesn’t change the value can be skipped, but I’m sure it can’t be done without breaking some source. (Source which deserves breaking, but one picks one’s battles…)</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>— F</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 21 Feb 2017, at 7:57 PM, Saagar Jha via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">It appears that trying to assign a variable to itself is an error:<div class=""><br class=""></div><div class="">var foo = 5</div><div class="">foo = foo // error: assigning a variable to itself</div><div class=""><br class=""></div><div class="">However, I was thinking about this and was wondering why this is an error and not a warning. If, for example, the assignment had a side effect (e.g. a didSet block) I’d think it would be warning, possibly ignorable with a set of parentheses. Thoughts?</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></body></html>