I realise the general opinion here seems to be that we don't want any more
changes to the access modifiers and I can understand why, but please take a
look at the use case below:
"fileprivate" is needed for certain things like Equatable since the equatable
function might need to know about private properties in a class. Lets say I
have two structs:
struct A {
...
}
struct B {
...
}
Both are rather big so I declare each in a separate file (File A, File B), but
I need to implement an equals function between these two structs that need
access to private properties in both structs. This leaves me with two options:
a) Move the two structs into one file and use fileprivate and implement the
equals function here. The result is one long messy file.
b) Move the two files into a separate module and use "internal" for the
variables I need acces to. This feels like overkill and struct A/B might have
dependencies that make this inconvenient.
Am I missing a more optimal solution here?
My point is there are legit use cases of fileprivate there might lead to one
really big file, with several classes. Having a folderprivate access level
would be one possible solution to this.
> On 8 Dec 2016, at 13.22, Rien via swift-evolution <[email protected]>
> wrote:
>
> Will discprivate be next? and then systemprivate? </facetious>
>
> -1
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
>
>
>
>
>> On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution
>> <[email protected]> wrote:
>>
>> Personal statement: –1
>>
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 8. Dezember 2016 um 12:26:17, Aron Lindberg ([email protected]) schrieb:
>>
>>> I think this is a great idea!
>>>
>>> I would prefer calling it folderprivate tho.
>>>
>>>> On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution
>>>> <[email protected]> wrote:
>>>>
>>>> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still
>>>> sleepy.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>>
>>>> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev
>>>> ([email protected]) schrieb:
>>>>
>>>>> You haven’t seen this in the list because no one requested
>>>>> dictionaryprivate yet. :D
>>>>>
>>>>> @core-team: See what you have done with >>file<<private thing.
>>>>> typerprivate, typepublic all these requests for new access modifiers.
>>>>>
>>>>> Instead of just going with
>>>>>
>>>>> private
>>>>> private(file)
>>>>>
>>>>> // for new one
>>>>> private(type)
>>>>>
>>>>> I know there would be some people that would forget about (file/type) and
>>>>> write only private everywhere, which is probably the main reason why we
>>>>> have fileprivate now.
>>>>>
>>>>> Anyways let’s be a little more constructive here.
>>>>>
>>>>> Hi Jim, regarding your request, it feels like this is something that
>>>>> falls into the topic of submodules. :) Correct me if I’m wrong here.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Adrian Zubarev
>>>>> Sent with Airmail
>>>>>
>>>>> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution
>>>>> ([email protected]) schrieb:
>>>>>
>>>>>> My apologies up front if I am going about this incorrectly. I have been
>>>>>> exploring extensions in Swift 3 both as a part of protocol-oriented
>>>>>> programming and as a way to encapsulate related code to improve
>>>>>> readability and maintainablity of otherwise more complex classes I have
>>>>>> designed. I am able to encapsulate methods and calculated properties in
>>>>>> extensions and restrict their use to the object type I am extending as
>>>>>> long as everything is in one file via fileprivate.
>>>>>>
>>>>>> I would like to be able to have my class or structure file in a
>>>>>> directory that contains my associated extensions (also in separate
>>>>>> files) and be able to restrict the access of appropriate properties and
>>>>>> methods to that common directory. This would allow the same level
>>>>>> encapsulation as fileprivate with the benifit of being able to organize
>>>>>> code into sepereate files based on function.
>>>>>>
>>>>>> I did not see this in the commonly rejected list but am unsure if this
>>>>>> is something that is out of scope for 4.0. Is this something I can write
>>>>>> up a proposal for? Is there some other approach that I missed that I
>>>>>> should be using instead?
>>>>>>
>>>>>> Kind regards,
>>>>>> Jim Malak
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> [email protected]
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
