> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution 
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

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?

Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to