[swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

Karl razielim at gmail.com
Mon Oct 17 12:59:37 CDT 2016


I was just doing some googling, turns out there was a discussion about nesting protocols in other types that seemed to go positively a long time ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html>

I would additionally like to propose that protocols be allowed to contain nested types (including other protocols). Relevant ABI issue is that the standard library contains enums for “FloatingPointRoundingRule”, “FloatingPointClassification” and “FloatingPointSign”. They would probably be better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc.

so to summarise, newly legal would be:

class MyClass {

    protocol Delegate {
    }
}

and also:

protocol MyProto {

    enum SomeValue {
    }

    protocol Delegate {
        associatedType ExpectedContent

	func receive(_: ExpectedContent, for: SomeValue)

        protocol SecondaryTarget {
            func receive(_ : ExpectedContent)
        }
    }
}

When conforming to a nested protocol, you can just use the name of the protocol:

class Host : MyProto.Delegate {
}

Except if a protocol in the chain has associated types, then you must use a concrete, conforming type instead (as you would in the first example — MyClass.Delegate):

class SecondaryProcessor : Host.SecondaryTarget {
}

If we’re good with this, I’ll write up a proposal.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161017/e6aaafc5/attachment.html>


More information about the swift-evolution mailing list