[swift-evolution] Type-based ‘private’ access within a file

[Chris Lattner]

On Apr 5, 2017, at 5:13 AM, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
>> Le 5 avr. 2017 à 0:02, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>>  - fileprivate should really become much more rare, which makes it more meaningful and significant where it occurs.  This was the original idea and intent behind SE-0025.
> 
> I think this will end up being a flawed assumption, just like last time.

I’m curious to know why you state this, you seem to agree with it below.

> Granted: there will be less need for `fileprivate` with this.

Right, glad to hear that you agree it will become more rare.

> Files that implement a type will not need `fileprivate` regardless of how many extensions they use to implement the type. But note that if there is only one type defined in that file (as is often the case), `private` has absolutely the same meaning as `fileprivate`.

Agreed on both points.

> Files that extend multiple types for the purpose of implementing a particular feature will still require `fileprivate` if those extensions want to share some implementation details.

Right.  That’s the part that makes fileprivate more meaningful.  This was exactly the *purpose* of having fileprivate in the first place.  We want to enable this sort of sharing of private implementation details, but we want to make it explicit at the point of declaration when something like that is going on.

> 
>>  - Similarly, this simplifies access control for most people.  Most people will now only care about private/internal/public.  fileprivate will become an expert feature used in specific cases to solve a specific class of problems.  Progressive disclosure of complexity is important.
> 
> People who only care about private/internal/public and ignore `fileprivate` will thus be restricted when it comes to using extensions on multiple types at the same time. If using `fileprivate`indeed  becomes rare or discouraged, this will shape the language away from such patterns.

Again, this is about progressive level of disclosure.  It looks like our QoI isn’t good enough right now, but the expected flow is that you write the invalid code (silly example here):

struct MyType {
  private var innards : T
}

extension String {
  func myHelper(x : MyType) {
     use(x.innards)
  }
}

You get the standard “innards is inaccessible due to private protection level” error message, but that message should have a note w/FixIt attached to it, offering to upgrade innards to fileprivate.

This approach is exactly why most people won’t have to care about it … until they need it.  At which point, the compiler provides an automatic onramp for them.

>>  - This design is true to the existing design of Swift: we want to encourage the implementation of types to be freely broken into extensions.  This alignment with extension oriented programming was the one important virtue of the Swift 1/2 access control design that Swift 3 lost.
> 
> This cut both ways. We want to encourage the implementation of types being freely broken into extensions. Great!. But do we want to discourage features implemented as extensions that spans across multiple types?

We don’t want to discourage them, we want to make them more explicit.  This was the intent of SE-0025, and I think the intent was good.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/192a6d4a/attachment.html>