[swift-evolution] final + lazy + fileprivate modifiers

[T.J. Usiyan]

"Either keep it or drop it, but don't keep fiddling with it." sums up my
position well.

On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Keeping with the spirit of Swift and staying consistent with its design,
> I see two plausible meanings for private:
> >
> > Private could mean either:
> > 1) private to the file (Swift 2 semantics)
> > 2) accessible only to the current type/scope and to extensions to that
> type that are in the current file.
> >
> > I don’t think we’ve ever evaluated and debated approach #2
> systematically.
>
> For what it's worth:
>
> I was opposed to SE-0025, but since I lost, I have tried to use `private`
> wherever it made sense, rather than fighting with the language.
>
> Sometimes, the change of keyword makes no difference. Other times, it's a
> hassle, because I have to switch between `private` and `fileprivate` as I
> redesign things, with little perceived benefit. I'd say the split between
> these is about 50/50.
>
> On a few occasions, I *have* genuinely appreciated the SE-0025 version of
> `private`. These involved cases where I wanted to ensure that instance
> variables were only manipulated in certain ways, using interfaces I had
> specifically designed to handle them correctly. For instance, I might have
> two parallel arrays, and I wanted to make sure that I only added or removed
> elements from both arrays at once. I could do this with `fileprivate` by
> splitting the type into two files, but it was more convenient to do it in
> one.
>
> In these cases, switching to #2 would *completely* defeat the purpose of
> using `private`, because the extensions would be able to directly
> manipulate the private instance variables. I would no longer gain any
> benefit at all from `private`. All of my uses would either fall into "makes
> no difference" or "it's a hassle".
>
> I do not support the idea of changing `private` to mean #2. Doing so would
> eliminate the few decent use cases I've found for `private`. Either keep it
> or drop it, but don't keep fiddling with it.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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/20170215/12b3c6f7/attachment.html>