Previously, we were binding optional l-values only when
performing an access. This meant that other evaluations
emitted before the formal access were not being
short-circuited, even if the language rules said they
should be. For example, consider this code::
var array : [Int]? = ...
array?[foo()] = bar()
Neither foo nor bar should be called if the array is
actually nil, because those calls are sequenced after
the optional-chaining operator ?.
The way that we currently do this is to project out
the optional address during formal evaluation. This
means that there's a formal access to that storage
beginning with the formal evaluation of the l-value
and lasting until the operation is complete. That's
a little controversial, because it means that other
formal accesses during that time to the optional
storage will have unspecified behavior according to
the rules I laid out in the accessors proposal; we
should talk about it and make a decision about
whether we're okay with this behavior. But for now,
it's important to at least get the right short-circuiting
behavior from ?.
Swift SVN r23608
This causes a regression in error reporting where there are potential fixes: <rdar://problem/17741575> Other than that, everything works.
Swift SVN r20230
