My standard reply is that when a type implementation gets this big, it is quite possible that the design is sub optimal.
An equate operation between types almost always means that they have something in common that can be isolated into its own file which then also includes the equate operation. 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 13:52, Aron Lindberg <[email protected]> wrote: > > 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
