[swift-evolution] final + lazy + fileprivate modifiers

[Xiaodi Wu]

That blog post starts out right away to say that it's a response to
community feedback. Moreover, the scenario you describe was just as
possible in 2014 as it is now. Finally, then as now, it's unclear why you
consider documentation to be "not pretty." After all, your reader would
need to consult the documentation before using a variable anyway.
On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm aware of this, but that's fairly a long time ago - before Swift was
> open source and had community feedback and before Swift was used widely
> among developers.
>
> To me, real-world use of the language has shown some flaws of missing a
> protected access control, mainly having to decide between having a variable
> internal or cramming all of the class extension into one file, making it a
> 3KLOC mess. Either solution is not pretty - now I have it split among
> several files with an internal variable commented as "Do not use, for
> private use of this class only."
>
> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez <cheyo at masters3d.com>
> wrote:
>
> https://developer.apple.com/swift/blog/?id=11
>
>
>
> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> How about removing fileprivate, getting Swift 2 meaning of private (as
> most people here now suggest) and add additional @protected annotation for
> those who want a more fine-grained solution:
>
> @protected private - members accessable only from the
> class/struct/enum/... and their extensions within the file
>
> @protected internal - again, but you can access it even from extensions
> and subclasses outside of the file within the entire module.
>
> @protected public/open - the same as above, but outside the modules.
>
> To me, this way most people here will be happy:
>
> - those wishing the access control gets simplified - it in fact does, you
> don't need to use @protected, if you don't want to/need to.
> - those who need a fine-grained solution, here it is.
>
>
>
> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> Sent from my iPad
>
> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> While we’re bikeshedding, I’m going to add my two cents. Hold on to your
> hat because this might be controversial here.
>
> I think both ‘private’ and ‘fileprivate’ are unnecessary complications
> that only serve to clutter the language.
>
> It would make a lot more sense to just have internal and public only. No
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>
>
> Eh, I've used `private` to keep myself honest in terms of going through
> some book-keeping functions instead of directly accessing a property.
>
>
> This is exactly the kind of thing I like it for and why I hope we might be
> able to keep scoped access even if it gets a new name that ends up as
> awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
>
>
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/f1c2912c/attachment.html>