[swift-evolution] Making capturing semantics of local
Slava Pestov
spestov at apple.com
Fri Oct 27 14:28:22 CDT 2017
> On Oct 27, 2017, at 10:51 AM, Mike Kluev <mike.kluev at gmail.com> wrote:
>
> On Thu, 26 Oct 2017 21:54:37 -0700 Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>
> Closures cannot replace all uses of local functions. Local functions can be recursive, and have a generic parameter list.
>
>
> FTM, local functions do not help with "keep functions short" and "keep indentation level small" rules of thumb.
So do structs and classes ;-)
> what are the actual benefits of local vs non local functions? locality principle? (define something where it is used). but we do not have it in much more important cases, say, with static variables - we have to declare them outside of functions. ditto for normal variables in extensions - no matter how carefully i group functions in individual extensions based on their purpose -- potentially in different files -- it all breaks once i need to add a single variable to that group which i have to to in the class itself.
Local functions can capture bindings from the outer function, just like methods can capture ‘self’ from the outer type. I don’t think a function with local functions is any less readable than a type declaration with methods. In many cases you can use both to solve the same problem, and the functional approach can be simpler.
> what would be the damage if we remove local functions altogether, would we lose anything really useful? aside from the fact that "it is too late at this stage" i mean (which is appreciated).
I mean, we could remove a lot of language features without giving up turing completeness. But I’ve personally used local functions in multiple languages and found them useful. I certainly don’t see why the feature is actively harmful, which is the criteria for introducing a source breaking change in Swift 5.
Slava
>
> Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171027/a5332d3a/attachment.html>
More information about the swift-evolution
mailing list