[swift-evolution] [Discussion] A Problem With SE-0025?

[Xiaodi Wu]

On Wed, Jun 29, 2016 at 11:03 AM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Jun 29, 2016, at 10:55 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Wed, Jun 29, 2016 at 10:52 AM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org>wrote:
>
>>
>> On Jun 29, 2016, at 10:46 AM, Sean Heber <sean at fifthace.com> wrote:
>>
>>
>> On Jun 29, 2016, at 10:22 AM, Matthew Johnson via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Jun 29, 2016, at 10:08 AM, David Hart <david at hartbit.com> wrote:
>>
>> Sorry if I wasn’t expressing myself well enough. In my original email, I
>> said that:
>>
>> The new rules make `private` more prominent compared to `fileprivate`
>> (the latter has a somewhat worse name).
>>
>>
>> So I agree that my issue is more with the naming than the functionality.
>> I’m mainly complaining that because of its name, `fileprivate` feels like
>> more of a special corner case of `private`. But in the style of writing
>> types through extensions, `fileprivate` will become much more prevalent
>> than `private`, which feels slightly backwards.
>>
>>
>> I don’t view it as more of a special corner case at all, but I can see
>> why you feel that way since it has an unprecedented (AFAIK) and more
>> verbose name.
>>
>> The proposal originally left `private` alone and used a new name for the
>> new access level.  We weren’t able to find a name that didn’t have problems
>> which led to the idea of renaming the existing `private`.
>>
>> My perspective is that it’s just the best name we could come up with for
>> the concept in the context of the various access levels we want to
>> support.  The name isn’t intended to discourage use in any way.
>>
>>
>> It may not be intended, but that doesn’t mean it won’t, though. :P
>>
>> I can’t say exactly *why*, but I feel similar to David here in that
>> “fileprivate” is such an… odd… name that I’m inclined to just not use it
>> and let things default to “internal” instead. In fact, I have *already*
>> caught myself doing this. I don’t know if that’s *bad* exactly (would more
>> things being internal actually aid the compiler/optimizer?),
>>
>>
>> I’m pretty sure more things being internal will not help the optimizer.
>> In fact, if you are not compiling with WMO turned on it could prevent
>> optimizations.
>>
>> but I think this is a valid concern. The issue here is rooted in
>> psychology, not technology. :/
>>
>>
>> That’s a fair perspective.  But a *significant* amount of time was spent
>> bike shedding this.  I’m not sure whether you and David participated or
>> not, but that was the time to have the naming discussion.
>>
>
> I think the case being made here is that `fileprivate` was settled on when
> it was thought that it would be rarely used. With what's emerged in this
> discussion, it turns out that `fileprivate` might be more useful than
> previously thought, and the awkwardness of the name therefore is more
> troublesome than when the naming discussion first took place.
>
>
> The example in this thread (placing data members in the type declaration
> and methods in extensions) is one that received ample discussion during the
> earlier threads and the review.
>
> I don’t know that `fileprivate` will be used in code more commonly than
> previously thought.  The issue is about the default access level of members
> inside a `private` type (i.e. when access is *not* directly specified).
> With Jordan’s proposed solution, `fileprivate` will be used to describe
> these members in documentation and diagnostics.
>
> It will also be possible to state this default explicitly, but I don’t
> think that will be too common.  This is the only change in what is possible
> to do *in code* from the original proposal.
>

You're adding words to my argument that I didn't put there. I didn't
specify "in code". Awkward is awkward, in code or in documentation.


>
>
>
>> IMO the value of having more control over visibility far outweighs a
>> slightly awkward name for file level visibility.  I don’t think it’s
>> anywhere near awkward enough to avoid, but I suppose YMMV.
>>
>>
>> l8r
>> Sean
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/69371f91/attachment.html>