[Proposal] Remove SectionInfoProtocol

[jessesquires]

These two protocols give us "flexibility" but do they really provide that much value? In practice, does anyone ever implement their own, or do they just use our concrete DataSource and Section types?

The main reasoning for these was not to impose using an Item array in sections and a Section array in DataSource -- that is, not impose the collection type on clients, so they could use their own collection that's not Array for each of these.

Given how this library works, and how TableView and CollectionView work, you have to use an array as your backing data source right now though. That is, you need an ordered, indexed collection.

Perhaps you could use a ordered set, but that doesn't exist in Swift (yet). (But you could use NSOrderedSet I guess.) But again, does this happen in practice? Certainly not often, if ever.

We currently define Section as:

public struct Section<Item>: SectionInfoProtocol {

    public var items: [Item]

    // ...
}

Maybe in Swift, we could probably express the generic collection attributes instead -- say we have a collection of Item and that collection conforms to MutableCollection, RandomAccessCollection, RangeReplaceableCollection. Then, clients could provide their own custom collections of Item.

Maybe be could do the same with DataSource and its array of sections?

[jessesquires]

cc @dcaunt and @psartzetakis -- would love your input / thoughts on this!

[jessesquires]

Nice 😎

Got this working in a playground:

public struct Section<T: MutableCollection & RandomAccessCollection & RangeReplaceableCollection> {

    public var items: T

    public let headerTitle: String?

    public let footerTitle: String?

    public var count: Int {
        return items.indices.count
    }

    public init(_ items: T, headerTitle: String? = nil, footerTitle: String? = nil) {
        self.items = items
        self.headerTitle = headerTitle
        self.footerTitle = footerTitle
    }

    public subscript (index: T.Index) -> T.Element {
        get {
            return items[index]
        }
        set {
            items[index] = newValue
        }
    }
}

extension Section where T: ExpressibleByArrayLiteral {
    public init(items: T.Element..., headerTitle: String? = nil, footerTitle: String? = nil) {
        self.items = T.init(items)
        self.headerTitle = headerTitle
        self.footerTitle = footerTitle
    }
}

[jessesquires]

Ah shit. This breaks with FetchedResultsController

EDIT: maybe 🤔

[jessesquires]

Ok, this gets really ugly pretty quick trying to integrate with DataSource since collection Indices aren't constrained to be of type Int -- that makes things even more complicated than they are now.

We can revisit the generic collection ideas later, after conditional conformances are implemented. #72

However, it's still worth removing SectionInfoProtocol -- this really is superfluous. We can make this concrete and use Section directly in DataSource. Clients can use our DataSource, or write their own DataSourceProtocol -- which we still need.