_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.
On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <email@example.com> wrote:
On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution < > firstname.lastname@example.org> wrote:
On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <email@example.com> 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.
On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <firstname.lastname@example.org> 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 < >> email@example.com> wrote:
Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution < >>> firstname.lastname@example.org> a écrit :
On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution < >>> email@example.com> wrote:
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.
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.
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/swif
t-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
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
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.
swift-evolution mailing list
swift-evolution mailing list
swift-evolution mailing list