[swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection
razielim at gmail.com
Thu Jul 7 10:04:28 CDT 2016
> On 7 Jul 2016, at 16:57, Karl <raziel.im+swift-evo at gmail.com> wrote:
>> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution <swift-evolution at swift.org> wrote:
>> This is a follow up from this swift-users thread: https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html
>> As it stands, RangeReplaceableCollection requires an implementation for init(), which is used in the default implementations of (as far as I can tell) init(_:), init(repeating:count:) and removeAll(keepingCapacity:). The latter of these methods should be implementable with removeSubrange(_:) instead.
>> I would like to propose to *remove* all three initialisers from this protocol, because it makes it impossible for some collections to conform to it that need extra data for its initialisation, but are otherwise perfectly capable of having arbitrary subranges replaced by elements from another collection. Those three initialisers could either move to a new protocol or simply not be part of any protocol.
>> On a similar note, I’d like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> I believe the idea of RRC is that all you need to implement is the empty initialiser and replaceSubrange(), and everything else (e.g. Append, insert) is implemented in terms of those. Even the initialiser which takes existing collection just initialises and empty one and appends the existing collection (I.e. Calling replaceSubrange).
> If I understand you correctly, it will not be possible to initialise a generic RRC any more, will it? Because that RRC may need additional information (e.g. A maximum buffer size if it stores its data in multiple discrete buffers) which you can’t provide generically.
> Maybe we could have a true copy-constructor instead? That is, replace init<C:Collection>(_:) with init(_: Self), so that it could take any additional arguments from that other instance?
Actually, a real copy-constructor would be a huge improvement in any case. Sometimes you want to copy a collection, but new Swift users may just assign it to a new reference expecting copy-on-write semantics. That will work for standard-library collections, but perhaps not for a collection which is a class. A formal copy constructor would solve that, but may be getting out of scope (or not, depending on what you were using those existing initialisers for…)
More information about the swift-evolution