Allow nested protocol declarations

[tdonnelly (Tim Donnelly)]

+1, I would still love to see nested protocols; it would remove so many unnecessarily verbose protocol names.

I'm curious if there would still be issues with protocols nested within generic types:

@Douglas_Gregor

class MyController<T> {
    protocol Delegate {
        // I’ve just created a parameterized protocol!
    }
}

It (naively) seems possible at this point: Foo<String>.Delegate and Foo<Int>.Delegate are simply different protocols (and I would assume that the generic params from the outer type would be available within the protocol).

[Douglas_Gregor]

@tdonnelly

It (naively) seems possible at this point: Foo<String>.Delegate and Foo<Int>.Delegate are simply different protocols (and I would assume that the generic params from the outer type would be available within the protocol).

It's not that it isn't possible to allow this and have them be different protocols; we could do that, and it's probably the most natural way of reading that code. My concern is that this is an indirect way to get to a major feature, generic protocols, and that we shouldn't go about a major expansion to the generics system indirectly. If we're going to end up with nested protocols with these semantics, they should be a result of having generic protocols as part of the language, and have dealt directly with all of the effects of such a feature.

Doug

[tdonnelly (Tim Donnelly)]

Makes sense – this particular case seems clear enough, but I would hate to see local decisions (for what is ultimately a small enhancement) force compromises down the road when generic protocols are picked up for real.

For what it's worth, that being the case: I am weakly in favor of waiting on nested protocols altogether until generic protocols can be comprehensively addressed, simply for consistency.

[DevAndArtist (Adrian Meister)]

All I can say to this is, "yes please". I love Swift's generics and these things from my point of view are simply holes in the language like for example missing opaque types/reverse generics or a generalization of the super-type constraint.

[kirilltitov]

Can't we just allow non-generic nested protocols for now, and discuss future of generic protocols more thoroughly some time later?

I mean, in 99% cases people just want namespacing. As an example: I'm working on a library FDBSwift which has one root name — FDB, containing all other things (like Transaction, Future, Tuple etc.), and it feels completely natural to hide all other declarations under that name, including protocols (because why not) (namings like FDBTransaction and FDBFuture are ugly when you have namespaces). But in reality I still have to have top-level protocols AnyFDBKey and FDBTuplePackable just because I'm not allowed to have nested protocols, and it drives my OCD crazy

[anandabits (Matthew Johnson)]

@Douglas_Gregor

It (naively) seems possible at this point: Foo<String>.Delegate and Foo<Int>.Delegate are simply different protocols (and I would assume that the generic params from the outer type would be available within the protocol).

It's not that it isn't possible to allow this and have them be different protocols; we could do that, and it's probably the most natural way of reading that code. My concern is that this is an indirect way to get to a major feature, generic protocols , and that we shouldn't go about a major expansion to the generics system indirectly. If we're going to end up with nested protocols with these semantics, they should be a result of having generic protocols as part of the language, and have dealt directly with all of the effects of such a feature.

Would these really need to be considered different protocols? Or could they be considered multi-parameter protocols (i.e. multi-parameter type classes) where some parameters are bound by the containing generic type?

I very much want to see both multi-parameter protocols and the ability to nest protocols in types and types in protocols. However, I think Improving the UI of Generics is a higher priority than these topics. In particular, I think the concern you express in the manifesto about people often really wanting generalized existentials when they bring up generic protocols is valid.