Anybody from core-team able to weigh in: do we want to keep this rule of not allowing parametrised protocols (in which case nesting is "trivial" - capturing is not allowed, only one protocol exists, so it's just namespacing), or is this something which should be deferred?
If possible I would like to include protocols inside of generic types. I kind of like the non-parameterised version. It's elegant and allows you to write generic conformers to the protocol. > > On Feb 7, 2017 at 4:10 pm, <Matthew Johnson (mailto:matt...@anandabits.com)> > wrote: > > > > > > > > > On Feb 6, 2017, at 11:12 PM, Karl Wagner via swift-evolution > > <swift-evolution@swift.org (mailto:swift-evolution@swift.org)> wrote: > > > > > > > > > > > > > > > > > > On 7 Feb 2017, at 06:05, Slava Pestov <spes...@apple.com > > > (mailto:spes...@apple.com)> wrote: > > > > > > > > > > > > > > > > > > > > > On Feb 6, 2017, at 9:00 PM, Karl Wagner via swift-evolution > > > > <swift-evolution@swift.org (mailto:swift-evolution@swift.org)> wrote: > > > > > > > > > > > > > > > > - Nested protocols in generic types are not parameterised by the > > > > parent's generic parameters. > > > > > > > > > > > > > > > > > > So if I write GenericType<Int>.SomeProto and > > > GenericType<String>.SomeProto, is it the same protocol? What about > > > GenericType.SomeProto, is that allowed? > > > > > > > > > > > > Slava > > > > > > > > > > > > > > GenericType.SomeProto (without parameters) is the only spelling that is > > allowed. There is no GenericType<Int>.SomeProto. > > > > > > > > That way we avoid every bound-generic type creating a new protocol. > > > > > > > > > > I have only had a chance to scan the proposal so I will probably have more > comments after I take a closer look, but I want to respond to this topic > right away. > > > > I understand the reason why you want it to work this way, but think it will > be a significant source of confusion. Protocols will behave differently > than any other entity nested in a generic type. This means the protocols > nested in generic types will likely be counterintuitive for most people. > > > > I know this was the case for me while I was scanning the proposal. I had > to think carefully to understand how you want this to work and why you want > this behavior. That is despite it being a relatively direct consequence of > the Swift’s design for protocols, which uses associated types and > intentionally does not allow generic protocols. > > > > It may be that there isn’t a good way to avoid that and we need to try to > address it through documentation and education. But I think this should > receive careful consideration before we commit to this direction. > > > > Overall the proposal looks really great! I’m really looking forward to > this feature. > > > > > > > > > > I think it works really nicely when you consider what it would like like > > with existential-based capturing. Notice that there is only one > > ‘MyCollectionView.Source’, and compatibility is determined based on > > existential constraints. > > > > > > > > - Karl > > > > > > > > > > > > > > class MyCollectionView<MediaItem> : UICollectionView { protocol > > Source { // [implicit] associatedtype MediaItem func item(at: > > Int) -> MediaItem var numberOfItems: Int { get } } var source: > > Any<MyCollectionView.Source where .MediaItem == MediaItem> // Not > > possible today. } class BookSource: MyCollectionView.Source { > > typealias MediaItem = Book func item(at: Int) -> Book { /* ... > > */ } var numberOfItems: Int { /* ... */ } } class > > DummySource<MediaItem>: MyCollectionView.Source where MediaItem: > > DummyConstructable { // associatedtype 'MediaItem' bound to generic > > parameter. func item(at: Int) -> MediaItem { /* ... */ } var > > numberOfItems: Int { /* ... */ } } MyCollectionView<Book>().source > > = BookSource() MyCollectionView<Book>().source = DummySource<Book>() > > MyCollectionView<Song>().source = DummySource() // type is: > > DummySource<Song> MyCollectionView<Movie>().source = DummySource() > > // type is: DummySource<Movie> > > > > > > > > > > > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org (mailto:swift-evolution@swift.org) > > https://lists.swift.org/mailman/listinfo
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
