<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 Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">- Sometimes (often?) refinements aren’t part of a grand design. &nbsp;They evolve in the mind space from usage of Swift. &nbsp;In other words, greedy optimization is sometimes just a natural way discussion and design happens. &nbsp;The question in my mind is when these concerns come up should we throttle individual proposals and take more time to take a broader view? &nbsp;Maybe that’s the answer. &nbsp;Having been in discussions in the Core Team meetings I can say that sometimes it is clear there is a broader topic to be discussed, and other times it isn’t.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>I would like to see an explicit place (maybe another list or a section of the eventual discourse) where we can ideate. &nbsp;Ideation requires a less critical environment than this list has been able to provide, and I think it has been contributing a great deal to our inability to deal with the larger picture. &nbsp;The exception to this are the manifestos provided by the core team, which I would guess are a result of off-list ideation sessions, followed by concentrated refinement.</div><div><br class=""></div><div>In the absence of an official place, it seems that there are a lot of ad-hoc places where this is being done in a fragmented way. &nbsp;The issue with this is that, when I see “We had a long discussion on Slack”, I don’t know where this Slack channel is, how to get an invite (or even if I am eligible for an invite). Even if I have access to all of the places this discussion is happening, it is so fractured that going back to find important bits of a part of a conversation later is nearly impossible.&nbsp;</div><div><br class=""></div><div>I would also like to see a place where ideas and known issues can be organized and referenced.</div><div><br class=""></div><div><i class="">A structure that has worked well in member-driven organizations I have been a part of in the past is that of working groups</i>. &nbsp;That is, we would larger identify areas of interest for the future development of swift (e.g. Strings), and then spawn a separate list or discourse section for deeper discussion (anyone who is interested could join). &nbsp;The group’s mandate would be to work through the big picture surrounding that issue (including an ideation stage) and develop a resulting manifesto. &nbsp;That manifesto should be an evolving document with known issues that need to be solved, and a record of attempted solutions which failed and the reason for their failure.</div><div><br class=""></div><div>I think this structure would take some pressure off of the core team and allow deep thinking on important topics. &nbsp;It would free the main list to focus on specific proposals based on the guideposts provided by the manifestos. &nbsp;Discussions like the Great Access Modifier War would have been contained to a working group, with the main list only receiving a recommendation at the end.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Concern #2 is that it’s hard to know what to do with a proposal when the ideal answer is “we need to see how it plays out in practice and then decide whether to accept it.” Theoretical discussion untempered by practical prototyping is a great way for a group to talk itself into a bad idea. (This will especially be a problem with future work to build out generics &amp; existentials.)<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I agree. &nbsp;Do you have specific thoughts here on what could be done differently?</span></div></blockquote></div><br class=""><div class="">I think we can partially solve this by having an extra stage of “stability” in our documentation. &nbsp;Right now, things are either officially part of the language or they aren’t (with a very short beta period between WWDC and the Fall). &nbsp;What I would like to see in the documentation is a notion of how sure we are of a particular piece of API or syntax.</div><div class=""><br class=""></div><div class=""><b class="">Unstable</b> - This is actively under development/design and should be expected to change. It is not safe to build frameworks on top of this.</div><div class=""><br class=""></div><div class=""><b class="">Pre-Stable</b> - We think we have a design which works, but we need to see how it works in the larger ecosystem before guaranteeing stability. &nbsp;Anything built on this should be prepared for potentially large changes in the future, and be marked “Pre-Stable” themselves.</div><div class=""><br class=""></div><div class=""><b class="">Stable</b> - This has been extensively tested in the actual swift ecosystem and proven itself a useful addition. &nbsp;Any changes to this in the future are guaranteed to either be source-compatible or have a full depreciation cycle. It is completely safe to build on.</div><div class=""><br class=""></div><div class="">I think being explicit about what we expect to change in the future, and having a notion of “stable” that is truly stable will give us a lot more freedom to experiment as well as room to fix our mistakes.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div></body></html>