[swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

[Xiaodi Wu]

On Fri, Dec 23, 2016 at 4:27 PM, David Sweeris <davesweeris at mac.com> wrote:

>
> On Dec 23, 2016, at 11:07, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Fri, Dec 23, 2016 at 1:33 PM, Callionica (Swift) <
> swift-callionica at callionica.com> wrote:
>
>> 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.
>>
>> I disagree that there is any significant risk that a novice user that
>> doesn'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's confusion. OTOH beginners that expect to be
>> able to use names that are in scope will be better off.
>>
>> In general I don't believe learning has the linearity you suggest and I
>> don't think there is anything particularly natural about the specific
>> sequence of concepts you've listed.
>>
>
> I'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.
>
> Put another way, the question is not whether it'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's
> possible to teach unrelated concept Y without reference to Z, for some
> reasonable ordering(s) of concepts from A to Z.
>
> 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'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.
>
> I think it'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.
>>
>> -- Callionica
>>
>
> If that's the only objection,
>

It's not. See Robert's excellent analysis.


> couldn't we put it behind a per-file "#enableScaryFeatures" flag?
>

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 "dialects" of
Swift.


> Maybe up by any import statements, so it's easy to see? Seems shortsighted
> to not let advanced programmers use a feature just because it's tricky for
> beginners.
>

There are many, many features that are tricky for _beginners_ in Swift, and
that's totally fine. The idea behind progressive disclosure is that it'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'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.

Or maybe "#enableExperimentalSyntaxes", for stuff that we know we want, but
> for which we don't yet have a syntax that's sufficiently "swifty" for us to
> commit to it (which would have the added "benefit" of giving us a place to
> put any feature whose syntax is a bit unstable).
>
> (That's it... I don't have much of an opinion one way or the other on the
> thread's proposal yet.)
>
> - Dave Sweeris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161223/3dd61cb1/attachment.html>