> On 7 Jul 2016, at 16:57, Karl <[email protected]> wrote: > > >> 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
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…) Karl _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
