> Le 5 avr. 2017 à 11:30, Chris Lattner <[email protected]> a écrit :
>
> On Apr 5, 2017, at 5:13 AM, Michel Fortin <[email protected]
> <mailto:[email protected]>> wrote:
>>
>>> Le 5 avr. 2017 à 0:02, Chris Lattner via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
