> On Mar 23, 2017, at 2:04 PM, Charles Srstka <[email protected]> wrote: > >> On Mar 23, 2017, at 1:21 PM, Matthew Johnson <[email protected] >> <mailto:[email protected]>> wrote: >> >> If we wanted to allow code like this to be written we wouldn’t need a new >> keyword to do it. You are proposing two things here: >> >> 1) Allow stored properties in same-module extensions. This has been >> discussed in the past and is a possibility, but I suspect it is not in scope >> for consideration during Swift 4. >> 2) Change the meaning of `private` to not mean lexical scope anymore, but >> instead be lexical scope or an extension of the type introducing the lexical >> scope in the same module. Changes to access control other than the proposal >> currently under review are out of scope for Swift 4. > > Neither, actually: > > 1) I’m proposing we no longer encourage extensions at all for this purpose. > My proposal is simply to allow breaking up declarations into parts, instead.
What I’m suggesting is that we could accomplish the same functionality by enhancing extensions. You can make a case that using a different keyword for same-module extensions that are allowed to have stored properties is a good idea. I’m not sure I would support that though. > > 2) I’m not proposing changing the meaning of ‘private’ here. Since partial > implementations would all glom into one lexical scope, all the current access > control rules would apply as they currently do. This is simply a way to write > a class or struct declaration in multiple parts, without having to use > extensions. This does not fit with any definition of “lexical scope” I am familiar with. I wouldn’t want to see Swift adopt this definition of lexical scope. > > Charles >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
