I haven't understood weak and strong references - objective-c

Question

By books first explains the problem (using ARC) about "unvalid" references, like in this example:
NSDate* date1=[[NSDate alloc]init];
NSDate* date2=date1;
[date1 release];
NSLog(#"%#",date2); // bad access
So I have understood the retain/release mechanism: in this case the instruction would be:
date2=[date1 retain];
But when it talks about strong/weak references, it sounds like a contradiction to me:
"By default, references are strong. If you assign an object to a strong reference, ARC assumes that you want that object to stick around and retains it implicitly"
Isn't this a contradiction of what has said before?
date2 is strong by default, so it should implicitly retain date1 and there wouldn't be a bad access exception.
Of course I have misunderstood something, could someone explain this better to me?

Answer 1

Strong is the default because it's typically what you want, but using ARC, the compiler analyzes how long the object's life needs to be and releases the memory at the appropriate time. For example:
- (void)someMethod
{
NSDate* date = [[NSDate alloc] init]; // date is __strong by default
NSLog(#"The date: %#", date); // date still contains the object created above
// Sometime before this point, the object date pointed to is released by the compiler
}
Weak references only keep the object around while it has one or more other strong references to it. As soon as the last strong reference is broken, the object is released by the compiler and the weak object reference (the variable) is changed to nil by the runtime. This makes weak variables almost useless in the local scope like the example above. For example:
- (void)someMethod
{
__weak NSDate* date = [[NSDate alloc] init]; // The date created is released before it's ever assigned to date
// because date is __weak and the newly created date has no
// other __strong references
NSLog(#"The date: %#", date); // This always prints (null) since date is __weak
}
To see an example of a weak and strong variable working together in the local scope (this would have only severely limited usefulness and is really shown here only to demonstrate weak variable references):
- (void)someMethod
{
NSDate* date = [[NSDate alloc] init]; // date stays around because it's __strong
__weak NSDate* weakDate = date;
// Here, the dates will be the same, the second pointer (the object) will be the same
// and will remain retained, and the first pointer (the object reference) will be different
NSLog(#"Date(%p/%p): %#", &date, date, date);
NSLog(#"Weak Date(%p/%p): %#", &weakDate, weakDate, weakDate);
// This breaks the strong link to the created object and the compiler will now
// free the memory. This will also make the runtime zero-out the weak variable
date = nil;
NSLog(#"Date: %#", date); // prints (null) as expected
NSLog(#"Weak Date: %#", weakDate); // also prints (null) since it was weak and there were no more strong references to the original object
}

Answer 2

The key mistake is in colluding manual-retain-release behavior and ARC as being identical. It isn't. Under ARC, object assignments are both atomic and, in and of themselves, expressions that determine object lifecycle.
Take your example and remove the retain. You end up with this:
NSDate* date1=[[NSDate alloc]init];
NSDate* date2=date1;
NSLog(#"%#",date2);
Makes perfect sense under ARC; there is no manual release screwing things up. I.e. it automatically just works.
Better yet, because the compiler does the flow control analysis behind the scenes, there is no extra retains or releases needed. The code will literally be something like:
NSDate* date1; // date1 initialized to nil -- or not given that it is never read before...
date1 = [[NSDate alloc]init]; // ... this assignment (of a +1 retain count obj)
NSDate* date2=date1; // retain count unchanged
NSLog(#"%#",date2); // retain count unchanged
.... compiler emits equivalent to [date1 release] ...
Since the compiler won't emit that release until after the last use of date1 or date2, there can never be a dangling pointer.