<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Protocols aren’t like parent-classes, they can’t be used interchangeably as different struct implementations of MyProtocol may have radically different memory footprints. I think you can define a protocol for classes only which may allow you to use MyProtocol as a concrete type, but personally I don’t like the idea of limiting a protocol in that way; the correct way to store elements of MyProtocol is to define a type-erased wrapper AnyMyType that takes any instance of MyProtocol and hides it.</div><div class=""><br class=""></div><div class="">Type-erased wrappers are bit of a pain in the ass to define; in fact, in the discussion you linked someone recommended a method using closures to do it, but while this is a neat way to do it, it’s very inefficient in terms of memory (if you have four or five methods in your protocol then suddenly the wrapper will be adding hundreds of bytes of overhead). The correct way to implement these is outlined in the following guide:</div><div class=""><br class=""></div><div class=""><a href="https://realm.io/news/type-erased-wrappers-in-swift/" class="">https://realm.io/news/type-erased-wrappers-in-swift/</a></div><div class=""><br class=""></div><div class="">This is a horrible process with a ton of boiler-plate though, so there’s certainly an argument to be made for features that can reduce or eliminate the need for this. In fact, it’d be great if protocols had type-erased wrappers generated automatically, as this could avoid the somewhat unintuitive cases like the one you’ve run into, but then it would end up hiding the complexity of what’s actually happening.</div><div class=""><br class=""></div><div class="">For example, if you want to save a bunch of different MyProtocol variations in a collection, then you might consider declaring them as classes with a common ancestor instead, then use that ancestor as your array type, as this is one of the advantage of classes over structs (even though I generally prefer the latter in most cases). Type-erased wrappers also add overhead that you should be aware of, but typically a lot less (if you use the boxing method, the closure method adds tons of overhead despite appearing much simpler).</div><br class=""><div><blockquote type="cite" class=""><div class="">On 30 Mar 2016, at 18:11, Jason Sadler via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">Hi folks,<br class=""><br class="">I have an issue with using a heterogeneous array of objects conforming to a protocol - I want to write an extension on Array (or CollectionType) that applies only when Element : MyProtocol, but I can’t call methods in that extension from an instance of [MyProtocol] because "Using ‘MyProtocol' as a concrete type conforming to protocol ‘MyProtocol' is not supported”<br class=""><br class="">(For more background, my full use case can be seen in this gist: <a href="https://gist.github.com/sadlerjw/2cc16b4375b02fe7f400" class="">https://gist.github.com/sadlerjw/2cc16b4375b02fe7f400</a>)<br class=""><br class="">I’ve asked about this on swift-users (<a href="https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160321/001560.html" class="">https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160321/001560.html</a>) and got some good workarounds but no one was able to provide me with information on any future plans in swift to address this issue - whether that’s making protocols conform to themselves, or some other improved approach to heterogeneous collections. I wonder if anyone here can shed some light on this? (I’m new to the mailing lists, sorry!)<br class=""><br class="">Thanks<br class="">Jason</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>