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 > <swift-evolution@swift.org> 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 > (adrian.zuba...@devandartist.com <mailto:adrian.zuba...@devandartist.com>) > 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 >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) 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 >>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
