[swift-users] Why does RangeReplaceableCollection require an empty initialiser?

Tim Vermeulen tvermeulen at me.com
Wed Jul 6 07:32:29 CDT 2016


> On 6 Jul 2016, at 14:03, Zhao Xin <owenzx at gmail.com> wrote:
> 
> According to the document of Swift 3, Array has already conformed protocol RangeReplaceableCollection.

That’s exactly why I also want to conform my wrapper to that protocol? I think there’s a misunderstanding. I’m making a collection that can be subscripted with any index (that conforms to Strideable), but behaves like an array otherwise.

> 
> Zhaoxin
> 
> On Wed, Jul 6, 2016 at 7:09 PM, Tim Vermeulen via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
> RangeReplaceableCollection has three initialisers: init(), init(_:) and init(repeating:count:). The latter two are implemented using the empty initialiser. But why are these initialisers part of this particular protocol? As far as I can tell, no other methods of this protocol depend on these initialisers. The requirement of the empty initialiser makes it impossible to have a collection conform to this protocol that needs additional data for its initialisation.
> 
> For instance, I was making an array that works with any Strideable indices, not just integers. A startIndex is needed for its initialisation, so I can’t really conform it to RangeReplaceableCollection. If I do it anyways (with a fatalError() in the required empty initialiser) everything seems to work just fine, except for the protocol’s three initialisers.
> 
> Perhaps these initialisers should be moved to a (possible new) different protocol?
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org <mailto:swift-users at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160706/d23ad0f3/attachment.html>


More information about the swift-users mailing list