Because it wouldn't make sense.
Before you start writing code that conforms to protocols, you need to think about your protocols and realize that in a normal use case (and the way that your protocols should be designed), code will be written only with knowledge of the protocol and with zero knowledge of any specific class or struct which implements the protocol.
So, it does make sense for the Fill protocol to have other protocols that inherit from it, such as SolidFill and perhaps StripedFill.
Let's go ahead and add the StripedFill protocol to your example. Now let's look at your Square struct and see why it doesn't implement the Shape protocol, which in part requires having a Fill property.
struct Square : Shape {
var sides : Int = 4
var fill : SolidFill = SolidFill(color: UIColor.blackColor())
}
The only thing we can assign to Square's fill property are things which implement the SolidFill protocol. But the Shape protocol requires that our shape be able to assign to a property called fill anything which conforms to the Fill protocol. And in the case where we also have a protocol called StripedProtocol which inherits from the Fill protocol, that would include objects that implement that protocol (whether or not they also implement the SolidFill protocol).
But your Square class doesn't allow for this. Your Square class only allows for one specific child of Fill and its descendants, but not its sibling... and the exclusion of SolidFill's potential siblings is why you can't do what you're trying to do.
What you can do however is this:
struct Square: Shape {
var sides: Int = 4
var fill: Fill = SolidFill(color: UIColor.blackColor())
}
So in this case, we're still definitely assigning a SolidFill to our Square, but we're still allowing for the fill property to match what it defined in the protocol and allowing for SolidFill's siblings to be assigned to the fill property.