<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="">The key difference is whether such things can be rolled out in the future in an additive way, potentially with extra compatibility affordances, vs whether something is inherent to the ABI as Swift and the standard library currently exists. This is a very fuzzy line, and is constantly getting reevaluated. But, generics features that change fundamental standard library internals such as Collection’s associated types fall more on the affects-current-ABI side of things, while additions that expose potential for new and better APIs fall on the ABI-additive side of things. </div><div class=""><br class=""></div><div class="">New and improved existential-backed APIs can be added while keeping around (or even deprecating) the older ones, but existing protocol hierarchies and their associated types can’t be easily uprooted. I apologize that this doesn’t shed a ton of light on the difference, but these things exist on a case-by-case basis.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 8, 2017, at 10:44 AM, Mathew Huusko V 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=""><div dir="auto" class="">Sorry to revive this, but back on my ABI stability education:</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Swift 5 planning was announced today (woohoo!) with a primary target on ABI stability. Finalising generics seems to be a major part of this, with "conditional conformances", "recursive protocol requirements," and "there are <span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class="">no known other generics enhancements needed for ABI stability" as key points.</span></div><div dir="auto" class=""><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class=""><br class=""></span></div><div dir="auto" class=""><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class="">But it seems like there's quite a bit more left in the generics manifesto unimplemented. Perhaps some of what's in there is controversial, but something like generalised existentials afaik *is/was* planned.. can someone explain how GE doesn't affect ABI stability?</span></div><div dir="auto" class=""><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class="">To my very naive mind it's not that different from some other things said to affect ABI, and to my slightly less naive mind, I believe it was going to enable a protocol oriented approach to KeyPaths in the future, which seems like it would affect ABI of stdlib.</span></div><div dir="auto" class=""><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class=""><br class=""></span></div><div dir="auto" class=""><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class="">I'm quite sure I'm missing the core concept at this point, so I'd be content with my examples being ignored and just pointing me towards a general/educational resource on ABI vs. interface thats vaguely compatible with Swift.</span></div><div dir="auto" class=""><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class=""><br class=""></span></div><div dir="auto" class=""><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";background-color:rgb(255,255,255)" class="">Thanks!</span></div><br class=""><div class="gmail_quote"><div class="">On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On Aug 7, 2017, at 11:34 PM, Elviro Rocca <<a href="mailto:retired.hunter.djura@gmail.com" target="_blank" class="">retired.hunter.djura@gmail.com</a>> wrote:<br class="">
><br class="">
> I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction:<br class="">
><br class="">
> - big efforts that add huge new features to the language so that things that were done in userland with libraries can be done natively and idiomatically (concurrent programming, for example);<br class="">
> - more "theoretical" big efforts, that allow one, while building a single app or a big library, to "express" more things more precisely in the language, and improvements to the generics and protocols systems fall in this second realm;<br class="">
><br class="">
> The reason why I consider the second kind of feature as more important than the first (thus, earning higher priority) is that, apart from reducing the amount of busywork to be done in many cases where the abstraction power is not good enough, it gives more tools for the community to build upon, it allows many people to do more with the language than probably me, you and the core team have ever though of, it fosters the explosion of creativity that's only possible when a language is expressive enough and it's not only based on certain conventions (that, by definition, constraint the way a language is commonly used).<br class="">
<br class="">
MHO is that both are important. I think the details of the tradeoffs involved prioritizing the individual members of those categories are bigger than the difference between the two categories. I don’t think this is a useful way to try to slice the problem up.<br class="">
<br class="">
-Chris<br class="">
<br class="">
</blockquote></div></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>