This is a recent regression that caused us to reject globals of
optional type that didn't have initializers <rdar://problem/16953669>.
Swift SVN r18332
by allowing default initializing let properties. In classes, the property
is mutable in init, and the default initialization is useful. The benefit we
gain by banning this is outweighed by the important usecases that get closed
off by doing so.
Swift SVN r18213
<rdar://problem/16264989> property not mutable in closure inside of its willSet
and:
<rdar://problem/16826319> willSet immutability behavior is incorrect
by changing how we handle immutability of an observing property within its willSet.
Instead of trying to model it as an rvalue, just model it as an lvalue (which it is)
and diagnose the problem with a warning in MiscDiagnostics.
Swift SVN r18184
have been type checked. This allows us to reliably determine the type of the variable
and to know whether it actually needs default initialization or not.
This fixes:
<rdar://problem/16620121> Initializing constructor tries to initialize computed property overridden with willSet/didSet
which was because we were doing default initialization before computing override sets.
This does regress on one case, where our fiddly default init code isn't realizing that
a default initializer will be generated. I fixme'd the case and filed:
<rdar://problem/16921173> implicit constructor synthesization runs too early
to track this.
Swift SVN r18094
There's a lot more work to do here, but start to categorize tests
along the lines of what a specification might look like, with
directories (chapters) for basic concepts, declarations, expressions,
statements, etc.
Swift SVN r9958
