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

[Xiaodi Wu]

On Wed, Jun 29, 2016 at 11:14 AM, Austin Zheng <austinzheng at gmail.com>
wrote:

> I just want a name that is:
>
> - a single English language word
> - whose common meaning has something to do with privacy, access,
> permissions, or a similar grouping concept that the other three keywords
> fits into
> - and intuitively describes the intensity of the behavior relative to the
> other three keywords
>
> I'm not sure if this is something we want to reopen, though, or what the
> right process would be.
>

Right. I agree with your criteria and your doubts about how to reopen the
topic. I'd offer that what's definitely not the right process is continuing
in this thread :)


>
> Austin
>
> On Wed, Jun 29, 2016 at 9:10 AM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Jun 29, 2016, at 11:06 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> 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.
>>
>>
>> That wasn’t intentional, sorry.  I misunderstood and thought you meant it
>> would be used more frequently in code than previously thought.  Thanks for
>> clarifying.
>>
>> I certainly don’t oppose a better name if anyone can suggest one that is
>> clearly better.  But I am skeptical that this is possible given the amount
>> of bike shedding that has already happened.
>>
>>
>>
>>>
>>>
>>>
>>>> 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
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> 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/bf493385/attachment.html>