As the title says, I think renaming `fileprivate` to `shared` is the simplest way to solve the issues we have with spelling.
My first line of reasoning is that it only affects one modifier, leaving private as it is. This minimises the amount of code affected, making it much more straightforward to migrate than the fileprivate-private-scoped switchup that has been suggested previously.
My justification for `shared` as the new spelling is that it expresses *why* the developer would use the access level - to share implementation details with something, be it an extension or another type. It sounds natural and first-class, and fits well within the hierarchy.
Private itself isn't too bad a default, and this change would leave it so, while making `shared` act as an informative identifier for where file-scope (or submodule-scope) sharing takes place. This would also hint at when the access level should be used from a design standpoint - more so than `fileprivate` or `file`.
That's a shame if true, but my interpretation was that the rejection specifically cited the double-rename of fileprivate to private, and private to scoped, a major change which renames two access modifier, and reuses a spelling, making a staged migration impossible.
Since this suggestion is less impactful - affecting only one keyword, using a spelling with no prior meaning, and can be done as a staged transition (we can keep fileprivate around in Swift 4 while allowing shared and adding a warning to fileprivate), I hoped the core team might be willing to consider it.
I think a lot of people would be pleased to be able to use a better spelling than fileprivate, even if it is never completely removed. This proposal would allow that.
···
On 6 Apr 2017, at 19:32, David Hart <david@hartbit.com> wrote:
Hi there,
During the discussion that followed the rejection of SE-0159 the Core Team explained that they would not consider any rename to access control keywords, for the same reasons behind SE-0159's rejection: source compatibility. So I'm fairly sure this suggestion would go very far.
David.
On 6 Apr 2017, at 16:30, James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:
As the title says, I think renaming `fileprivate` to `shared` is the simplest way to solve the issues we have with spelling.
My first line of reasoning is that it only affects one modifier, leaving private as it is. This minimises the amount of code affected, making it much more straightforward to migrate than the fileprivate-private-scoped switchup that has been suggested previously.
My justification for `shared` as the new spelling is that it expresses *why* the developer would use the access level - to share implementation details with something, be it an extension or another type. It sounds natural and first-class, and fits well within the hierarchy.
Private itself isn't too bad a default, and this change would leave it so, while making `shared` act as an informative identifier for where file-scope (or submodule-scope) sharing takes place. This would also hint at when the access level should be used from a design standpoint - more so than `fileprivate` or `file`.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
That's a shame if true, but my interpretation was that the rejection
specifically cited the double-rename of fileprivate to private, and private
to scoped, a major change which renames two access modifier, and reuses a
spelling, making a staged migration impossible.
That's my understanding as well. The core team's promise at the end of
SE-0025 was that they would entertain future suggestions for `fileprivate`
should a superior spelling come about.
Since this suggestion is less impactful - affecting only one keyword, using
···
On Thu, Apr 6, 2017 at 3:20 PM, James Froggatt via swift-evolution < swift-evolution@swift.org> wrote:
a spelling with no prior meaning, and can be done as a staged transition
(we can keep fileprivate around in Swift 4 while allowing shared and adding
a warning to fileprivate), I hoped the core team might be willing to
consider it.
I think a lot of people would be pleased to be able to use a better
spelling than fileprivate, even if it is never completely removed. This
proposal would allow that.
> On 6 Apr 2017, at 19:32, David Hart <david@hartbit.com> wrote:
>
> Hi there,
>
> During the discussion that followed the rejection of SE-0159 the Core
Team explained that they would not consider any rename to access control
keywords, for the same reasons behind SE-0159's rejection: source
compatibility. So I'm fairly sure this suggestion would go very far.
>
> David.
>
>> On 6 Apr 2017, at 16:30, James Froggatt via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> As the title says, I think renaming `fileprivate` to `shared` is the
simplest way to solve the issues we have with spelling.
>>
>> My first line of reasoning is that it only affects one modifier,
leaving private as it is. This minimises the amount of code affected,
making it much more straightforward to migrate than the
fileprivate-private-scoped switchup that has been suggested previously.
>>
>> My justification for `shared` as the new spelling is that it expresses
*why* the developer would use the access level - to share implementation
details with something, be it an extension or another type. It sounds
natural and first-class, and fits well within the hierarchy.
>>
>> Private itself isn't too bad a default, and this change would leave it
so, while making `shared` act as an informative identifier for where
file-scope (or submodule-scope) sharing takes place. This would also hint
at when the access level should be used from a design standpoint - more so
than `fileprivate` or `file`.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution