[discussion] final + lazy + fileprivate modifiers


(David Hart) #1

I was reading this nice listing of Swift keywords (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI stability set in.

I'm listing them here but it might be worth starting separate discussions for each of them.

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?

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?

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.

Thanks for hearing me out!

David.


(Chris Lattner) #2

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.

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

···

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:


(Matthew Johnson) #3

I was reading this nice listing of Swift keywords (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI stability set in.

I'm listing them here but it might be worth starting separate discussions for each of them.

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?

Final is used abundantly by the teams I have worked with. These are iOS apps with no external consumers of the module. My experience is that it is a very useful communication of intent to future readers of the code.

That aside, I think the criteria for a change are different now. Your criteria were relevant during the big breaking change era of Swift 3. I think the criteria for removing a feature at this point should be: is it causing problems that justify the breaking change required to remove it?

···

On Feb 12, 2017, at 10:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

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?

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.

Thanks for hearing me out!

David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Michel Fortin) #4

The following is only anecdotal of course. In my code base I went to the trouble of changing everything that could to `private`. I find I have to use `fileprivate` 21% of the time: 105 occurrences of fileprivate, 387 for private.

`fileprivate` is often necessary because I have a tendency to separate various parts of the code related to a type in multiple thematic extensions in the same file. Often there is one extension per protocol conformance, keeping the conformance declaration close to the implementation. And in many cases the implementation in the extension needs access to private details of the type, which requires `fileprivate`.

I also have cases where the extension is rather pointless and would be better if merged into the base type. Those often require `fileprivate` too. Cleaning that up is very low priority though, so `fileprivate` remains.

I guess that makes one data point.

···

Le 12 févr. 2017 à 12:24, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

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.

--
Michel Fortin
https://michelf.ca


(Charlie Monroe) #5

I was reading this nice listing of Swift keywords (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI stability set in.

I'm listing them here but it might be worth starting separate discussions for each of them.

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?

To me, it's useful a lot. The module doesn't necessarily be a 1KLOC framework - I've been recently refactoring a 90KLOC module and the final keyword was fairly useful since some subclasses used hacks by overriding some vars or methods. This allowed me to look at it from a different perspecitve, make some members final and create better API endpoints for customization.

Not to mention that it allows the compiler to access stored properties directly when they're final - if I recall correctly someone from the core team mentioning that.

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?

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 like the scoped access, I actually find it useful when declaring several classes within one file, so that I know I'm not accessing that class' private members. That said, I agree that the change to fileprivate was IMHO a mistake - aside from the fact that I dislike the fileprivate keyword, I was more leaning towards the idea that fileprivate would be default for private and when someone really wants to make some member scope-private, private(scope) could be used.

···

On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Thanks for hearing me out!

David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jean-Daniel) #6

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.

···

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :
On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #7

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.

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.

I’m 50/50 on this idea. If SE-0025 was the right decision, then this is a good suggestion. It will push people towards using fileprivate only when necessary. But it also has the consequence of biasing future stats towards the fact that SE-0025 was a good idea. For example, imagine we had introduced a folderprivate access modifier, and added a warning that pushed towards using folderprivate when internal was not necessary, it would give credit to folderprivate because we would see it in much more code: people just applying the fix-it. But it doesn’t mean anything about folderprivate being a good idea in the first place. Does that make sense?

···

On 12 Feb 2017, at 18:24, Chris Lattner <clattner@nondot.org> wrote:
On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-Chris


(Vanderlei Martinelli) #8

Well. I really would like to see something like this in Swift:

public(open|closed)
protected // (yes, we and Cocoa still use classes)
internal
private(file)

I would like the abstract modifier to any access level because, well... We
and Cocoa still use classes. :wink: It could be something like
protected(abstract) (I’m getting the syntax from private(set) thing).

The fileprivate addition meaning the previous `private` was a mess (after
we accustomed to the private Swift’s semantic since access levels were
introduced). And the open keyword as it was implemented in Swift 3.x makes
code like open func close() { .. } difficult to understand for a newbie and
ugly for a experienced programmer.

final and lazy are good as they are today.

My 2 cents.

Regards,

Vanderlei Martinelli

···

On Sun, Feb 12, 2017 at 2:19 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:

I was reading this nice listing of Swift keywords (https://medium.com/the-
traveled-ios-developers-guide/swift-keywords-v-3-0-1-
f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not
long for this world and I was thinking if we needed/could deprecate them
before any kind of ABI stability set in.

I'm listing them here but it might be worth starting separate discussions
for each of them.

*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?

*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?

*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.

Thanks for hearing me out!

David.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #9

I was reading this nice listing of Swift keywords (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI stability set in.

I'm listing them here but it might be worth starting separate discussions for each of them.

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?

Final can be consumed (so to speak) by other types within the module. It's not strictly an in-module/out-of-module decision the way public and open are.

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?

Groff!

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 use both.

-- E, one data point

···

On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:


(William Sumner) #10

I find the “Motivation” section of SE-0025 convincing. Private/fileprivate allows for distinguishing between shared and hidden details among related code in a file. Not only is there benefit in knowing intent when reading, but there is also benefit in writing because the IDE won’t autocomplete hidden details. I work on large files I’m not the sole author of, so this is important to me.

Preston

···

On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

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.


(Slava Pestov) #11

I was reading this nice listing of Swift keywords (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI stability set in.

I'm listing them here but it might be worth starting separate discussions for each of them.

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?

Adding or removing ‘final’ on a non-open class, or members of a non-open class, will not change ABI.

Slava

···

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

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?

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.

Thanks for hearing me out!

David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Slava Pestov) #12

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?

Changing a property from ‘lazy’ to computed or a property behavior etc is going to be an ABI-compatible change, so deprecating this feature or replacing it with a standard library feature (with the appropriate syntax sugar to keep old code compiling) is certainly feasible after the ABI freeze.

Slava

···

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

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.

Thanks for hearing me out!

David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #13

I was reading this nice listing of Swift keywords (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI stability set in.

I'm listing them here but it might be worth starting separate discussions for each of them.

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?

To me, it's useful a lot. The module doesn't necessarily be a 1KLOC framework - I've been recently refactoring a 90KLOC module and the final keyword was fairly useful since some subclasses used hacks by overriding some vars or methods. This allowed me to look at it from a different perspecitve, make some members final and create better API endpoints for customization.

Not to mention that it allows the compiler to access stored properties directly when they're final - if I recall correctly someone from the core team mentioning that.

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?

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 like the scoped access, I actually find it useful when declaring several classes within one file, so that I know I'm not accessing that class' private members. That said, I agree that the change to fileprivate was IMHO a mistake - aside from the fact that I dislike the fileprivate keyword, I was more leaning towards the idea that fileprivate would be default for private and when someone really wants to make some member scope-private, private(scope) could be used.

I also like the scoped access control but think we probably made a mistake in the choice of keywords. The problem was that nobody could come up with a name for specifying scoped access that had broad consensus. I hope that if somebody identifies a really obviously good keyword for scoped access that we might consider making a breaking change to fix this problem. But I think it would have to be very clearly better, and even then may not provide enough benefit to justify a breaking change.

···

On Feb 12, 2017, at 10:34 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks for hearing me out!

David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #14

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@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@swift.org> wrote:

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #15

_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.

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.

···

On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre@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@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@swift.org> wrote:

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution < >> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #16

I should add, on the topic of looking at real-world evidence: the question
we really want to answer is, "Are authors taking advantage of (or finding
useful) the new distinction between private and fileprivate?" To me, that
people are leaving the migrator's `fileprivate` in place suggests that in
general they don't much know or care about this distinction.

AFAICT, implementing a warning when `fileprivate` is too broad answers a
different question, "Is `fileprivate` still necessary in as many places as
it seems now that `private` is still here?" But, that's just asking for a
straightforward measurement of how often (file)private members are accessed
outside the private scope. What it doesn't tell you is whether Swift users
are finding the distinction between private and fileprivate to be
meaningful. In fact, if this warning were to be implemented and a large
swing happens in `private` vs. `fileprivate`, I'd argue that we'd just
demonstrated that Swift users aren't paying attention to the distinction at
all, just mashing the buttons.

···

On Sun, Feb 12, 2017 at 2:35 PM, Xiaodi Wu <xiaodi.wu@gmail.com> 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.

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.

On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre@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@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@swift.org> wrote:

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution < >>> swift-evolution@swift.org> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution < >>> swift-evolution@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/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
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #17

_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.

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.

···

On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre@nondot.org <mailto:sabre@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@gmail.com <mailto:xiaodi.wu@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #18

_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 <matthew@anandabits.com> wrote:

On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre@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@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@swift.org> wrote:

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution < >>> swift-evolution@swift.org> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution < >>> swift-evolution@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/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
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #19

_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. 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 Feb 12, 2017, at 3:45 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre@nondot.org <mailto:sabre@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@gmail.com <mailto:xiaodi.wu@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #20

_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?

Maybe that’s an exception, but maybe not. I don’t think we know yet and I

···

On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 12, 2017, at 3:45 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <matthew@anandabits.com> > wrote:

On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:

think this is what Chris is hoping to learn.

On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre@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@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@swift.org> wrote:

Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution < >>>> swift-evolution@swift.org> a écrit :

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution < >>>> swift-evolution@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/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
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution