> On 7 Jul 2016, at 17:19, Tim Vermeulen <[email protected]> wrote:
>
>>
>> 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.
>
> Right, but as it turns out, the empty initialiser is used in barely any of
> them.
>
>> 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.
>
> Correct. I haven’t come up with a use for initialising a generic RRC anyways,
> mostly because I think there are RRCs for which an empty init wouldn’t make
> any sense.
>
>>
>> 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?
>
> This is certainly an improvement over init(), but what would it be used for
> with regards to this particular protocol? It might certainly be useful, but
> the empty initialiser can be useful as well; it’s just a matter of how
> relevant that method is to this protocol. Wouldn’t a copy constructor make
> more sense in the more general Collection protocol?
>
>>
>> Karl
I have a use-case: I have a struct which wraps a RangeReplaceableCollection and
allows you to tag ranges of indices with random objects (it’s actually pretty
cool, it can automatically merge adjacent ranges of Equatables — sort of like a
pure-Swift NSAttributedString). It needs to create a new collection (currently
via the initialiser, but a copy-constructor would also be fine), because it
needs to own the indexes for mutability guarantees.
Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
