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
