These types are often useless and confusing to users who expect to be able to use Sequence or Generator as types in their own right like in C# or Java. While we're here, relax the rules for self-conformance to admit methods returning 'Self'. Covariant return types should not actually prevent a protocol type from conforming to itself, and the stdlib makes particular use of protocols with 'init' requirements which implicitly return Self.
Swift SVN r18989
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
We weren't diagnosing initializer delegation/chaining, subscripts, or
(the one that got me concerned) members accessed through AnyObject.
Swift SVN r18271
Normally, protocol conformances are only checked for types and extensions
declared in the current file. However, for protocols that can derive their
conformances (like RawRepresentable), other files in the target might
expect to be able to use the protocol members (like toRaw), which aren't
written in the source. Force the derivation if this is the case.
Also, move the /other/ set of RawRepresentable tests from test/Parse to
test/Sema.
<rdar://problem/15936403>
Swift SVN r14162
This attribute states that all stored properties within the class must
provide initial values. This will allow us to move stored property
initialization into Objective-C's post-allocation initialization hook,
.cxx_construct.
Swift SVN r12228
var decls. I was originally intending to use this for argument lists, but I
don't think that's a great direction to go anymore.
In any case, it seems uncontroversial to enforce immutability on foreach
enumation patterns, so I did that (see testcase)
Swift SVN r11124
We still want to allow line wrapping, so only issue the warning when the indentation of the expression and the return keyword is the same.
radar://11945406
Swift SVN r9984
rdar://14151649 suggests that it should be a warning, but I don’t see a reason
why it should not be an error. We have no legacy code that relies on this.
Swift SVN r9976
