[Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection


(Tim Vermeulen) #1

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(_:slight_smile: 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鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.


(Haravikk) #2

+1 from me, if the ability to Self() initialise isn't absolutely required then these should be removed.

路路路

On 7 Jul 2016, at 06:50, Tim Vermeulen via swift-evolution <swift-evolution@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(_:slight_smile: 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.


(Karl) #3

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鈥檛 provide generically.

Maybe we could have a true copy-constructor instead? That is, replace init<C:Collection>(_:slight_smile: with init(_: Self), so that it could take any additional arguments from that other instance?

Karl

路路路

On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution <swift-evolution@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(_:slight_smile: 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鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #4

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(_:slight_smile: instead.

You can't implement `removeAll(keepingCapacity: false)` with
`removeSubrange(_:)`. How do you propose to provide the other default
implementations?

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.

I agree with the goal, but I'd like to see an implementation before I
agree that it's acheivable.

路路路

on Wed Jul 06 2016, Tim Vermeulen <swift-evolution@swift.org> wrote:

Those three initialisers could
either move to a new protocol or simply not be part of any protocol.

On a similar note, I鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave


(Karl) #5

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

路路路

On 7 Jul 2016, at 16:57, Karl <raziel.im+swift-evo@gmail.com> wrote:

On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution <swift-evolution@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(_:slight_smile: 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鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
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鈥檛 provide generically.

Maybe we could have a true copy-constructor instead? That is, replace init<C:Collection>(_:slight_smile: with init(_: Self), so that it could take any additional arguments from that other instance?

Karl


(Tim Vermeulen) #6

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(_:slight_smile: 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鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
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鈥檛 provide generically.

Correct. I haven鈥檛 come up with a use for initialising a generic RRC anyways, mostly because I think there are RRCs for which an empty init wouldn鈥檛 make any sense.

Maybe we could have a true copy-constructor instead? That is, replace init<C:Collection>(_:slight_smile: 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鈥檚 just a matter of how relevant that method is to this protocol. Wouldn鈥檛 a copy constructor make more sense in the more general Collection protocol?

路路路

On 7 Jul 2016, at 16:57, Karl <razielim@gmail.com> wrote:

On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution <swift-evolution@swift.org> wrote:

Karl


(Dmitri Gribenko) #7

I agree that we need to see an implementation to be able to evaluate
the suggestion.

Dmitri

路路路

On Thu, Jul 7, 2016 at 6:14 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Wed Jul 06 2016, Tim Vermeulen <swift-evolution@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(_:slight_smile: instead.

You can't implement `removeAll(keepingCapacity: false)` with
`removeSubrange(_:)`. How do you propose to provide the other default
implementations?

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.

I agree with the goal, but I'd like to see an implementation before I
agree that it's acheivable.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Haravikk) #8

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.

路路路

On 7 Jul 2016, at 15:57, Karl via swift-evolution <swift-evolution@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鈥檛 provide generically.

Maybe we could have a true copy-constructor instead? That is, replace init<C:Collection>(_:slight_smile: with init(_: Self), so that it could take any additional arguments from that other instance?


(Tim Vermeulen) #9

> 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(_:slight_smile: instead.
You can't implement `removeAll(keepingCapacity: false)` with
`removeSubrange(_:)`. How do you propose to provide the other default
implementations?

You鈥檙e right, I didn鈥檛 think that through properly. My first thought was a copy constructor for collections in general, but as you pointed out, this wouldn鈥檛 be efficient for this purpose. An 鈥渆mpty copy constructor鈥 would be better, which could be either a static method, an instance method, a computed property or an initialiser. I鈥檇 probably opt for the computed property (it will always run in O(1) anyways, I think), but it doesn鈥檛 really matter.

路路路

on Wed Jul 06 2016, Tim Vermeulen<swift-evolution@swift.org>wrote:

> 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.
I agree with the goal, but I'd like to see an implementation before I
agree that it's acheivable.

> Those three initialisers could
> either move to a new protocol or simply not be part of any protocol.
>
>
> On a similar note, I鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave


(Dave Abrahams) #10

Maybe RRC should have:

聽聽聽聽聽聽func emptyCopy() -> Self

?

路路路

on Thu Jul 07 2016, Haravikk <swift-evolution@swift.org> wrote:

On 7 Jul 2016, at 15:57, Karl via swift-evolution <swift-evolution@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鈥檛 provide
generically.

Maybe we could have a true copy-constructor instead? That is,
replace init<C:Collection>(_:slight_smile: 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.

--
Dave


(Karl) #11

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鈥檚 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

路路路

On 7 Jul 2016, at 17:19, Tim Vermeulen <tvermeulen@me.com> wrote:

On 7 Jul 2016, at 16:57, Karl <razielim@gmail.com> wrote:

On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution <swift-evolution@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(_:slight_smile: 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鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
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鈥檛 provide generically.

Correct. I haven鈥檛 come up with a use for initialising a generic RRC anyways, mostly because I think there are RRCs for which an empty init wouldn鈥檛 make any sense.

Maybe we could have a true copy-constructor instead? That is, replace init<C:Collection>(_:slight_smile: 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鈥檚 just a matter of how relevant that method is to this protocol. Wouldn鈥檛 a copy constructor make more sense in the more general Collection protocol?

Karl


(Karl) #12

Perhaps we should have a shallow-copy protocol for Collections in general?

I was using the initialiser to create a copy, but that鈥檚 not really anything to do with a 鈥渞ange-replaceable collection鈥 and there may be non-RRCs which you want to take shallow copies of for similar composition guarantees.

Karl

路路路

On 8 Jul 2016, at 03:18, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Thu Jul 07 2016, Haravikk <swift-evolution@swift.org> wrote:

On 7 Jul 2016, at 15:57, Karl via swift-evolution <swift-evolution@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鈥檛 provide
generically.

Maybe we could have a true copy-constructor instead? That is,
replace init<C:Collection>(_:slight_smile: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karl) #13

What I mean by that is that the wrapper needs to make sure that you never mutate the collection it references outside of its own replaceSubrange. Otherwise the parallel collection of tagged indexes would go out-of-sync.

Karl

路路路

On 7 Jul 2016, at 19:10, Karl <raziel.im+swift-evo@gmail.com> wrote:

On 7 Jul 2016, at 17:19, Tim Vermeulen <tvermeulen@me.com <mailto:tvermeulen@me.com>> wrote:

On 7 Jul 2016, at 16:57, Karl <razielim@gmail.com <mailto:razielim@gmail.com>> wrote:

On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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(_:slight_smile: 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鈥檇 like to have all initialisers of SetAlgebra removed as well, but that might need its own review.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
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鈥檛 provide generically.

Correct. I haven鈥檛 come up with a use for initialising a generic RRC anyways, mostly because I think there are RRCs for which an empty init wouldn鈥檛 make any sense.

Maybe we could have a true copy-constructor instead? That is, replace init<C:Collection>(_:slight_smile: 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鈥檚 just a matter of how relevant that method is to this protocol. Wouldn鈥檛 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鈥檚 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


(Dave Abrahams) #14

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鈥檛 provide
generically.

Maybe we could have a true copy-constructor instead? That is,
replace init<C:Collection>(_:slight_smile: 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@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,
to which I refer you in order to spare the list. :slight_smile:

I was using the initialiser to create a copy, but that鈥檚 not really
anything to do with a 鈥渞ange-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.

路路路

on Sat Jul 09 2016, Karl <swift-evolution@swift.org> wrote:

On 8 Jul 2016, at 03:18, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jul 07 2016, Haravikk <swift-evolution@swift.org> wrote:

On 7 Jul 2016, at 15:57, Karl via swift-evolution <swift-evolution@swift.org> wrote:

--
Dave


(Haravikk) #15

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.

路路路

On 11 Jul 2016, at 19:16, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Jul 09 2016, Karl <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 8 Jul 2016, at 03:18, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Thu Jul 07 2016, Haravikk <swift-evolution@swift.org> wrote:

On 7 Jul 2016, at 15:57, Karl via swift-evolution <swift-evolution@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鈥檛 provide
generically.

Maybe we could have a true copy-constructor instead? That is,
replace init<C:Collection>(_:slight_smile: 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@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. :slight_smile:

I was using the initialiser to create a copy, but that鈥檚 not really
anything to do with a 鈥渞ange-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.