[swift-evolution] final + lazy + fileprivate modifiers

Sun Feb 12 18:07:11 CST 2017

I find the final keyword useful when I want to communicate that this class
should not be subclassed.

I think the behavior should remain the same since it is useful.

On Sun, Feb 12, 2017 at 5:15 PM Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

> On Feb 12, 2017, at 3:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>
> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>
> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't
> actually meaningful. Here's why:
>
> If I see `fileprivate` and can understand that to mean "gee, the author
> _designed_ this member to be visible elsewhere inside the file," then it's
> actually meaningful. OTOH, if I see `fileprivate` and can only deduce "gee,
> the author mashed some button in his or her IDE," then it's not really
> telling me anything.
>
>
> You’re looking at it backward.  It’s when you see `private` and can deduce
> “this member is only visible inside it’s declaring scope” that can be
> really helpful.  *This* is what matters.
>
>
> In what ways can that information help you?
>
> What you've said above, as I understand it, is that it's not currently
> meaningful to see `fileprivate` because the migrator is writing it and not
> the author. The improved approach you proposed is the additional warning.
> In that case, the compiler will help to ensure that when I see
> `fileprivate`, at least I know it's necessary. But that's only telling me a
> fact (this member is accessed at least once outside the private scope), but
> it's still machine-based bookkeeping, not authorial intent.
>
>
> The important thing is that this machine-based bookkeeping results in a
> proof about the code.  This facilitates reasoning about the code.  You can
> make an argument that this proof is not important enough to matter, but you
> must admit that this is a real concrete gain in information that is
> immediately available to a reader of the code (after they know that it
> compiles).  Personally, I find this proof to be valuable.
>
>
> Comparison has been made to `let` and `var`. In that case, whether a
> variable is mutated can be non-trivial to deduce (as Swift has no uniform
> scheme for distinguishing mutating from non-mutating functions; the ed/ing
> rule has many exceptions). By contrast, here, I don't see any gain in
> information. You can literally *see* where the (file)private member is
> accessed, and when a file gets too long, even a simple text editor can do a
> decent enough find.
>
> If you're right that the real value is that seeing `private` helps you
> reason about the code, then that value must be commensurate to how often we
> see Swift users amending the migrator to take advantage of it. For me, the
> compelling evidence that Swift users don't find this proof to be valuable
> is that, by examination of Swift 3 code, Swift users haven't bothered. If
> we add a new fix-it to force them to, then of course they'll mash the
> buttons, but it's pretty much declaring that they are wrong not to care
> about what it seems they do not care at present.
>
>
> This is really subjective and it’s not clear to me that there is
> substantial evidence one way or another.  I know that `private` is valued
> and used heavily by the teams I have worked with.
>
>
> It wasn't a rhetorical question that I asked: what value do you perceive
> in the new `private` in terms of helping you reason through code?
>
>
> You are right that any time it really matters it’s not hard to answer the
> question with a search, so it’s largely a convenience.
>
> That said, I find it quite useful to be able to mark helper methods and
> types within an extension `private` to make it clear that they are indeed
> local helper methods or types that are not accessed more broadly.  This
> communicates an intent.  As long as your extensions don’t get too large, a
> whole extension is usually visible on a single screen on a 27” iMac which
> is very useful - you don’t have to consider code that is scrolled out of
> sight.
>
> I also find it useful to be able to mark stored properties `private` and
> therefore *not* available to extensions.  This can facilitate tighter
> encapsulation of state, especially when there is a handful of basis methods
> through which the extensions access that state.
>
>
> Maybe that’s an exception, but maybe not.  I don’t think we know yet and I
> think this is what Chris is hoping to learn.
>
>
> On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre at nondot.org> wrote:
>
> I don't fully agree: you are right that that is the case when writing
> code.  However, when reading/maintaining code, the distinction is
> meaningful and potentially important.
>
> -Chris
>
> On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> If the overwhelming use case is that developers should pick one over the
> other primarily because it looks nicer, then blindly click the fix-it when
> things stop working, then the distinction between private and fileprivate
> is pretty clearly a mere nuisance that doesn't carry its own weight.
> On Sun, Feb 12, 2017 at 13:33 Jean-Daniel via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> *Final*
> Can someone tell me what is the use of 'final' now that we have 'public'
> default to disallowing subclassing in importing modules? I know that
> 'final' has the added constraint of disallowing subclassing in the same
> module, but how useful is that? Does it hold its weight? Would we add it
> now if it did not exist?
>
>
> As Matthew says, this is still important.
>
> *Lazy*
> This one is clearer: if Joe Groff's property behaviors proposal from last
> year is brought forward again, lazy can be demoted from a language keyword
> to a Standard Library property behavior. If Joe or anybody from the core
> team sees this: do we have any luck of having this awesome feature we
> discussed/designed/implemented in the Swift 4 timeframe?
>
>
> Sadly, there is no chance to get property behaviors into Swift 4.
> Hopefully Swift 5, but it’s impossible to say right now.
>
> *Fileprivate*
>
> I started the discussion early during the Swift 4 timeframe that I regret
> the change in Swift 3 which introduced a scoped private keyword. For me,
> it's not worth the increase in complexity in access modifiers. I was very
> happy with the file-scope of Swift pre-3. When discussing that, Chris
> Latner mentioned we'd have to wait for Phase 2 to re-discuss it and also
> show proof that people mostly used 'fileprivate' and not the new 'private'
> modifier as proof if we want the proposal to have any weight. Does anybody
> have a good idea for compiling stats from GitHub on this subject? First of
> all, I've always found the GitHub Search quite bad and don't know how much
> it can be trusted. Secondly, because 'private' in Swift 2 and 3 have
> different meanings, a simple textual search might get us wrong results if
> we don't find a way to filter on Swift 3 code.
>
>
> I would still like to re-evaluate fileprivate based on information in the
> field.  The theory of the SE-0025 (
> https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md)
> was that the fileprivate keyword would be used infrequently: this means
> that it would uglify very little code and when it occurred, it would carry
> meaning and significance.
>
>
> Infrequent use and significance are orthogonal.
> I still think developers would declare all ivars private (this is less
> ugly and shorter), and then will happily convert them to fileprivate each
> time the compiler will tell them they are not accessible somewhere else in
> the file.
> As the code that try to access that ivar is in the same file anyway, it
> has full knowledge of the implementation details and there is no good
> reason it shouldn’t be able to access the ivar when needed.
>
> We have a problem with evaluating that theory though: the Swift 2->3
> migrator mechanically changed all instances of private into fileprivate.
> This uglified a ton of code unnecessarily and (even worse) lead programmers
> to think they should use fileprivate everywhere.  Because of this, it is
> hard to look at a random Swift 3 codebase and determine whether SE-0025 is
> working out as intended.
>
> The best way out of this that I can think of is to add a *warning* to the
> Swift 3.1 or 4 compiler which detects uses of fileprivate that can be
> tightened to “private” and provide a fixit to do the change.  This would be
> similar to how we suggest changing ‘var’ into ‘let’ where possible.  Over
> time, this would have the effect of getting us back to the world we
> intended in SE-0025.
>
> -Chris
>
> _______________________________________________
> 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/20170213/a801cc11/attachment.html>