swift234

Conversions between like-optional types are treated as optional-to-optional, which can be problematic if the arities of the two optional types are different, but the most-bound types are the same. In these cases the type checker will generate a bind/inject/evaluate sequence, which may inadvertently flatten nested optionals to a 'nil' value. (rdar://problem/17412649) What we really want here is something similar to a value-to-optional conversion, but inner expressions may not yet be simplified during constraint generation, so we'll need to "peephole" it in during application.

It looks like the code for generating optional-to-optional conversions may still have problems with nested optional subtype conversions, but I don't think the application phase is the right place to address them. To holistically address this class of problem, we may want to reconsider how these kinds of optional conversions are threaded through the constraint solver post-1.0.

Swift SVN r19731