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

[Michel Fortin]

> Le 5 avr. 2017 à 11:30, Chris Lattner <clattner at nondot.org> a écrit :
> 
> On Apr 5, 2017, at 5:13 AM, Michel Fortin <michel.fortin at michelf.ca <mailto: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.

To clarify: I agree there would be less need for `fileprivate`. I just don't think it'll be that much less that it'll qualify as rare.

Perhaps we just don't have the same rarity threshold, or we are not looking at the same kind of code. "Rare" is a rather subjective measurement.


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

If that fixit only shows up rarely, and if people always take its suggestion to fix the access level of the declaration when it appears, wouldn't that signify the distinction between the two access levels is not very meaningful in the first place?

The only way I see `private` having real meaning is if someone teaches himself to write `fileprivate` by default instead of `private`. Then when the compiler complains about something being `private` he will know he is accessing something that was *intentionally* locked under a stricter access level, making him think about what he is doing before changing it. Whereas with everything under a stricter access level than necessary by default, relaxing access levels becomes a normal thing to do and the stricter access level doesn't offer much protection anymore.

The sole mistake with SE-0025 in my opinion was to make `private` something people would use by default instead of `fileprivate`. The language should make people explicitly choose the stricter access level when useful instead of making it the default choice. That would have given real meaning to that choice. That would have made relaxing an access level something worth some scrutiny.

Right now we have the total opposite to scrutiny: we want  to see the strict access level relaxed almost automatically with a Fixit as soon as it becomes a hindrance. It's only considered a good thing because everybody knows most `private` declarations are perfectly fine being `fileprivate`. It's unfortunate that the few declarations that really need to stay `private` will risk the same Fixit treatment without anybody noticing.

Seems like I'm ranting about something that's already decided now. So I'll stop and return to more productive things.

-- 
Michel Fortin
https://michelf.ca

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