<div dir="ltr">On Fri, Dec 23, 2016 at 4:27 PM, David Sweeris <span dir="ltr">&lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div><br></div><div>On Dec 23, 2016, at 11:07, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Fri, Dec 23, 2016 at 1:33 PM, Callionica (Swift) <span dir="ltr">&lt;<a href="mailto:swift-callionica@callionica.com" target="_blank">swift-callionica@callionica.<wbr>com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I support the principle of progressive disclosure. I still fail to see how if class capture were introduced it would prevent people from learning about classes, functions, closures or any other existing concept in whatever order the student or teacher preferred.</div><div><br></div><div>I disagree that there is any significant risk that a novice user that doesn&#39;t expect to be able to use names that are in scope would be worse off with this change. Think about the exact sequence of events that has to occur to trigger this user&#39;s confusion. OTOH beginners that expect to be able to use names that are in scope will be better off. </div><div><br></div><div>In general I don&#39;t believe learning has the linearity you suggest and I don&#39;t think there is anything particularly natural about the specific sequence of concepts you&#39;ve listed.</div></blockquote><div><br></div><div>I&#39;m making no claim that learning _has_ to be linear or ought to be, nor that any particular sequence of learning is _particularly_ natural. Rather, I understand the notion of progressive disclosure to mean that there ought to be _some_ sequence or sequences of learning where it is possible to master things in a linear fashion _if_ any particular learner wishes to proceed linearly, with concepts introduced earlier not making reference to concepts learned later. It is entirely fair if someone finds it more intuitive to learn or teach the same material in a different order, or even to learn or teach multiple concepts simultaneously.</div><div><br></div><div>Put another way, the question is not whether it&#39;s reasonable to have all learners progress through Swift in one particular blessed way. The question is whether, _if_ a learner is not yet ready to learn concept Z, it&#39;s possible to teach unrelated concept Y without reference to Z, for some reasonable ordering(s) of concepts from A to Z.</div><div><br></div><div>In this analysis, I think that classes capturing variables from a containing function would be detrimental. If one considers classes, functions, and closures as three topics, it is currently possible (I think) to master classes and functions without reference to closures. In a scenario where classes can capture variables in a containing function, one must understand the concept of escaping closures to master classes and functions. The argument isn&#39;t that one linear sequence of learning is superior to the others; the argument is that a reasonable linear ordering of these concepts conducive for at least some learners would become non-linear by having this new feature.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I think it&#39;s worthwhile to analyze features from the point of view of beginner users of the language, but I reach the opposite conclusion in this case.</div><span class="m_9020485080928818946HOEnZb"><font color="#888888"><div><br></div><div>-- Callionica</div></font></span></blockquote></div></div></div></div></blockquote><br></span><div>If that&#39;s the only objection,</div></div></blockquote><div><br></div><div>It&#39;s not. See Robert&#39;s excellent analysis.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>couldn&#39;t we put it behind a per-file &quot;#enableScaryFeatures&quot; flag?</div></div></blockquote><div><br></div><div>This has been an idea brought up in the distant past about other features. The core team has said very clearly that they do not want &quot;dialects&quot; of Swift.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Maybe up by any import statements, so it&#39;s easy to see? Seems shortsighted to not let advanced programmers use a feature just because it&#39;s tricky for beginners.</div></div></blockquote><div><br></div><div>There are many, many features that are tricky for _beginners_ in Swift, and that&#39;s totally fine. The idea behind progressive disclosure is that it&#39;s possible to design features of arbitrary complexity in a pedagogically sound way. Attention to the learning and teaching aspects of language design does _not_ mean accommodating beginners at the expense of advanced users. It&#39;s precisely the most advanced features that need the greatest thought and care devoted to the teachability of their design, so that the greatest number of people can learn the most advanced features in the most approachable way.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Or maybe &quot;#enableExperimentalSyntaxes&quot;, for stuff that we know we want, but for which we don&#39;t yet have a syntax that&#39;s sufficiently &quot;swifty&quot; for us to commit to it (which would have the added &quot;benefit&quot; of giving us a place to put any feature whose syntax is a bit unstable).</div><div><br></div><div>(That&#39;s it... I don&#39;t have much of an opinion one way or the other on the thread&#39;s proposal yet.)</div><div><br></div><div>- Dave Sweeris</div></div></blockquote></div><br></div></div>