Is that (i.e. having properties in extensions) listed in the completing generics manifesto? It certainly seems like it'd be a worthwhile feature to consider under that umbrella.<br><br>The one place where it will complicate matters is in the use of protocol extensions as traits, since what I know of traits is that they should not encapsulate state.<br><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 10, 2016 at 14:13 Paul Cantrell <<a href="mailto:cantrell@pobox.com">cantrell@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I do certainly agree that 5 access levels are _plenty_, C++ “friend” is no great friend to me, and I too not want to see another one access level added. However, I do think there’s a related problem here worth solving.</div><div><br></div><div>Sometimes, trying to break apart a large type using extensions, I encounter this pattern:</div><div><br></div><div>class Thingamer {</div><div> private var doodads: [Doodad]</div><div><br></div><div> // All of these use the doodads var:</div><div><br></div><div> public func mangleDoodads() { … }</div><div> public func fungeDoodads() { … }</div><div> public func renoberateDoodads() { … }</div><div> private func doodadHelper() { … }</div><div><br></div><div> // …and no other methods touch it</div><div>}</div><div><br></div><div>My first instinct in this situation is to pull all the doodad-related stuff into a separate type, but sometimes that’s the wrong solution. Perhaps the public API gets messy or nonsensical if those public doodad-related methods aren’t on Thingamer. Perhaps other Thingamer methods use those doodad methods, even if they don’t use the private var. Perhaps there’s still coupling to Thingamer through other class properties. And so forth.</div><div><br></div><div>It would be great to group all the doodad-stuff into an extension. The inability of extensions to use class-private vars is the barrier. My usual solution is to make the doodads var internal, and then try to remember not to use it outside of the extension — which looks a lot like “fake friend”.</div><div><br></div><div>It would be nice if Swift extensions let us encapsulate state+behavior relationships without having to create new type boundaries.</div><div><br></div><div>IIRC, there was talk of extensions being able to add properties to an existing type. It seems like this would be feasible, at least for types within the same module? Perhaps there’s another better way?</div><div><br></div><div>Cheers,</div><div><br></div><div>Paul</div></div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Sep 10, 2016, at 11:28 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="white-space:pre-wrap">Agreed.<br><br>Swift's access levels are deliberately defined in terms of contiguous blocks of written code [this is inelegantly phrased, but I think you see what I mean]. As such, neither a "class scoped" level nor a level shared between a type and its extensions would fit in such a scheme.<br><br>Such an addition would fundamentally counter the existing design of Swift, open the door for compensating features such as "friend classes" that (IIUC) were deliberately avoided, and fails to compose with existing access levels as inevitably there will be proposals to do. By that I mean, why should a "class scoped" member always be limited in visibility to the same module? This satisfies your particular motivating use case, but someone else will want the same kind of class scoping but also allow a member to be accessed by extensions outside the module (classpublic, if you will); still others will want a member to be overridable outside the module (classopen); for good measure, some will want access limited to only extensions and not other types in the same file (classfileprivate; it is not out of the question for someone to raise this point, since it is a close cousin of the argument for distinguishing private and fileprivate).<br><br>If I had my druthers, it'd be nice to have exactly something like Nevin's idea, a terse way to group related files into submodules, and a keyword like `subinternal` that restricts visibility to that group of files. It would satisfy the motivating use case here while preserving the deliberate design decision that Swift access levels do not pick and choose non-contiguous chunks of multiple files.<br><br>In any case, let's postpone this discussion until it comes into scope at a later phase of Swift evolution. The core team and other experts would no doubt have much to contribute at that time.</div><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 10, 2016 at 09:31 Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Indeed, I find it rather less convenient to write “fileprivate” in many places I previously would use “private”, and unfortunate that I must choose between aggregating many pieces into a single lengthy file or else polluting the module scope with implementation details.<div><br></div><div>I agree with Xiaodi that submodules are a far cleaner design, and I would very much like to replace “fileprivate” with a short word that implies “private to the submodule”. Then by default each file could be its own submodule, and a developer could opt into having more files in a submodule if they so desire.</div><div><br></div><div>Count me as opposed to any sort of “class scoped” access level.</div></div><div dir="ltr"><div><br></div><div>Nevin</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 10, 2016 at 10:01 AM, Rien via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I am firmly against this. The 5 levels that we have cover us well and have enough complexity already.<br>
<br>
</span>Agree.<br>
<div><div><br>
<br>
<br>
> On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> I agree that classprivate would probably not work, maybe constructprivate? but then you are leaving our enum etc.<br>
> With the `internal(class)` suggestion, if declaring a var such as `internal(set) var name: String?` would this become `internal(class, set) var name: String?`<br>
> Also there would need to be some kind of compile check either way because if you declared an enum for example outside of a constructor you would not be able to mark it as our new constructor only access level or it would become inaccessible throughout the project.<br>
><br>
> Re: submodules, they are indeed overkill for this. As you would need a separate submodule for each class you wanted to do this with and then run the risk of inter coupling lots of different really small submodules.<br>
><br>
> Suggestions so far:<br>
> `classprivate`<br>
> `constructprivate`<br>
> `private(instance)`, `private(instance, set)` - problem -> how would this work? `public private(instance, set)`<br>
> `internal(class)`<br>
><br>
> Personally I think a name like `classprivate` or `constructprivate`, although not particularly well named would reduce complexities with private setters syntax and keep migrations much simpler.<br>
><br>
><br>
> On Sat, 10 Sep 2016 at 07:09 Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> I don't think submodules would solve it nicely. Each module/submodule will require it's own namespace + it feels like an overkill to create submodules for a few types. `internal(xyz)` seems to me like a better solution. And yes this is purely additional and nothing for phase 1.<br>
><br>
> --<br>
> Adrian Zubarev<br>
> Sent with Airmail<br>
> Am 9. September 2016 um 19:09:12, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:<br>
><br>
>> Isn't the general solution to this problem submodules? In any case, seems like it'd be out of scope for Swift 4 phase 1.<br>
>><br>
>><br>
>> On Fri, Sep 9, 2016 at 11:34 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>> There must be a better solution to this problem, because you might also extend value types from different files. That would mean, we'd need `structprivate` `protocolprivate` etc.<br>
>><br>
>> How about: `internal(class)` etc. ? Or something like `internal(private)` to rule them all (I don't like the last name, but something that would rule them all would be nice to have)!<br>
>><br>
>><br>
>> --<br>
>> Adrian Zubarev<br>
>> Sent with Airmail<br>
>> Am 9. September 2016 um 17:49:29, Tom Bates via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:<br>
>><br>
>>> There is currently no way of accessing "shared code" from extensions declared outside the base .swift file<br>
>>><br>
>>> I would love to see along side the new fileprivate access level a classprivate access level that would allow any extension declared outside of the original .swift file to access these properties and functions in an attempt to reuse code.<br>
>>><br>
>>> an example is below...<br>
>>><br>
>>> =================<br>
>>> //MyClass.swift<br>
>>> public class MyClass {<br>
>>><br>
>>> classprivate func sharedFunction() {<br>
>>> self.function1()<br>
>>> self.function2()<br>
>>> }<br>
>>><br>
>>> fileprivate func function1() {}<br>
>>> fileprivate func function2() {}<br>
>>> }<br>
>>> =================<br>
>>><br>
>>> =================<br>
>>> //MyClass+Save.swift<br>
>>> extension MyClass {<br>
>>><br>
>>> public func save() {<br>
>>> self.someFunction()<br>
>>> self.sharedFunction()<br>
>>> }<br>
>>><br>
>>> fileprivate func someFunction() {}<br>
>>> }<br>
>>> =================<br>
>>><br>
>>> Currently to achieve anything like this you would have to make the "core" functions public or internal or write the whole thing in a single file which as I understand it is not optimal for the compile speed and can get unmanageable for large classes. This would allow a more managed file structure and the separation of related functions from the core declaration.<br>
>>><br>
>>> There would be no migration needed I don't think as the impact on current code would be zero until the developer adopts the new access level<br>
>>><br>
>>> Regards,<br>
>>> Tom<br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
>><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></blockquote></div>