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

[T.J. Usiyan]

I want this feature. Both class in protocol and protocol in class could
clean up many relationships but I think that a blocking concern is "How
does this interact with generics?" Nesting types in generic types is
already disallowed and how different is this feature from that?

On Mon, Oct 17, 2016 at 2:20 PM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> Two weeks ago there was a similar pitch here https://lists.swift.org/
> pipermail/swift-evolution/Week-of-Mon–20161003/027643.html
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027643.html>
>
> In general I’m in favor of this feature, but I don’t know any technical
> issues this might have or does already have.
>
> As I said in the other thread.
>
>    -
>
>    I’m for nested everything.
>    -
>
>    Nested extensions to reduce noise at some point, BUT this should not
>    remove extension A.B { … } completely.
>
>    class A {
>
>        class B { … }
>
>        extension B { … } // extends A.B
>    }
>
>    -
>
>    We already have A.B syntax for extensions, why don’t we allow it for
>    type declarations to reduce nesting (sometimes you don’t want to cluster
>    everything)? Basically something like class A.B { … } would be a
>    shortcut for extension A { class B { … } } and is bounded by the
>    access modifier of A. (This is probably additive.)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Oktober 2016 um 19:59:54, Karl via swift-evolution (
> swift-evolution at swift.org) schrieb:
>
> 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
>
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161017/fed334aa/attachment.html>