[swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

[Haravikk]

> On 11 Jul 2016, at 19:16, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Sat Jul 09 2016, Karl <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>> On 8 Jul 2016, at 03:18, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> on Thu Jul 07 2016, Haravikk <swift-evolution at swift.org> wrote:
>>> 
>> 
>>>>> On 7 Jul 2016, at 15:57, Karl via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> 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?
>>>> 
>>>> A copying initialiser could work, but it should probably have a
>>>> parameter for the type of copy to create (empty, shallow copy and deep
>>>> copy for example), as I suspect it's the empty copy that
>>>> RangeReplaceableCollection needs more than anything. Otherwise it
>>>> shouldn't need initialisers on the protocol. This however is something
>>>> that could (and should) be moved out into its own protocol I think,
>>>> with RangeReplaceableCollection simply conforming that.
>>> 
>>> Maybe RRC should have:
>>> 
>>>     func emptyCopy() -> Self
>>> 
>>> ?
>>> -- 
>>> Dave
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> Perhaps we should have a shallow-copy protocol for Collections in
>> general? 
> 
> Please read my rant about deep-vs-shallow copy at
> http://news.gmane.org/find-root.php?message_id=m2a8k3evnt.fsf%40fripp.apple.com <http://news.gmane.org/find-root.php?message_id=m2a8k3evnt.fsf%40fripp.apple.com>,
> to which I refer you in order to spare the list. :-)
> 
>> I was using the initialiser to create a copy, but that’s not really
>> anything to do with a “range-replaceable collection” and there may be
>> non-RRCs which you want to take shallow copies of for similar
>> composition guarantees.
> 
> The problem is that the operation for which RRC has an empty initializer
> is not going to copy the elements.  So any implementation of that method
> that is based on copying elements would be inefficient.  
> 
> I am also *very* reluctant to have protocol requirements for making
> explicit true-copies when values are automatically copied and when we
> have no way to constrain generics to things with value semantics.  That
> gets into waters for which we have no design and I don't want to set a
> precedent without sufficiently considering the design space.

Ah, well in that case it's probably better to forget about copying for now then. Still Karl's suggestion could be tweaked slightly like so:

	init(emptyCopyOf:Self)

To clarify that the copy is to be empty, while giving a reference to pull any other required values from that the empty initialiser alone cannot provide.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/b163ec2a/attachment.html>