[swift-evolution] namespacing protocols to other types

[Kelvin Ma]

vv

On Sun, Dec 24, 2017 at 11:36 PM, Howard Lovatt <howard.lovatt at gmail.com>
wrote:

> I would say yes they are different for the example. Definitely something I
> miss is nesting types to given a seperate namespace.
>
> -- Howard.
>
> > On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > There was a proposal to allow protocols to be nested inside types at one
> point but it didn’t move forward.
> >
> > Basically, if the outer type is a non-generic class, struct or enum,
> there’s no conceptual difficulty at all.
> >
> > If the outer type is a generic type or another protocol, you have a
> problem where the inner protocol can reference generic parameters or
> associated types of the outer type. This would either have to be banned, or
> we would need to come up with coherent semantics for it:
> >
> > struct Generic<T> {
> >  protocol P {
> >    func f() -> T
> >  }
> > }
> >
> > struct Conforms : Generic<Int>.P {
> >  func f() -> Int { … } // Like this?
> > }
> >
> > let c = Conforms()
> > c is Generic<String>.P // is this false? Ie, are Generic<Int>.P and
> Generic<String>.P different protocols?
> >
> > Slava
> >
> >> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> is there a reason why it’s not allowed to nest a protocol declaration
> inside another type?
> >> _______________________________________________
> >> 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/20171224/510ffa79/attachment.html>