<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Jan 2017, at 08:04, Russ Bishop 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 class=""><br class=""><blockquote type="cite" class="">On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class=""><br class="">Would love to see this come forward into discussion.<br class=""></blockquote><br class="">Yeah. I'm less sure about the other enhancements to existentials fitting into Swift 4, e.g., the creation of existentials for protocols with associated types. Although important, it's a big feature that will take a bunch of design and implementation time, and I'm leery of accepting something that we might not actually be able to achieve. <br class=""><br class=""> - Doug<br class=""></blockquote><br class="">By this are you referring to generalized existentials? If so I’ll say this is such a constant pain point and perverts so many API designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In my completely non-authoritative personal opinion we shouldn’t ship Swift 4 without it :)<br class=""><br class=""><br class="">Russ<br class="">_______________________________________________<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></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">There is one little thing we could do to make that easier to live with: we could allow closure properties to satisfy function requirements on protocols.</div><div class=""><br class=""></div><div class="">It’s on my wishlist of things to propose in phase 2: <a href="https://gist.github.com/karwa/52b35a8a1f3bebc24264df5aeb2aa761#allow-function-requirements-in-protocols-to-be-satisfied-by-closure-type-properties" class="">https://gist.github.com/karwa/52b35a8a1f3bebc24264df5aeb2aa761#allow-function-requirements-in-protocols-to-be-satisfied-by-closure-type-properties</a></div><div class=""><br class=""></div><div class="">- Karl</div><a href="https://gist.github.com/karwa/52b35a8a1f3bebc24264df5aeb2aa761#allow-function-requirements-in-protocols-to-be-satisfied-by-closure-type-properties" class=""></a></body></html>