With synthesized iVars, we've had direct access to the underlying synthesized variable for a while now, so if you created a class like this:
You're able to access the NSString variable foo that backs the property of the same name within the scope of your class. So, in your dealloc method, you can do this, to give one common example:
However, if you enable the "synthesize by default" feature in LLVM 1.5 and use it, meaning you don't actually have a @synthesize statement for the foo property, you lose this direct access to the underlying variables, leaving you with a bit of a conundrum - how do you do your memory cleanup without unintentionally triggering unwanted functionality, such as those in a lazy accessor or some more involved mutators.
Earlier today, I tweeted a question asking about the correct way to deal with this situation. After a bit of a Who's on First-like back and forth with many smart people, it finally came out that this is a bug in LLVM, not an intentional design decision. Hopefully it will be fixed before too long, but in the meantime, the best answer is probably to just keep using @synthesize.
Thanks to a whole bunch of people on Twitter, many of whom I'm sure I missed!