> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> On 10 Apr 2017, at 08:21, Jean-Daniel <mail...@xenonium.com> wrote: >>> >>> >>> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution >>> <swift-evolution@swift.org> a écrit : >>> >>> >>> >>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>> >>>>> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> This struck me as a bit odd at first, but the more I think about it, the >>>>> more I really like the ability to nest extensions/scopes. The one issue >>>>> I see is sticking that public extension inside a private one. I think >>>>> you would have to mark ‘secret: Int’ as private instead of the extension >>>>> itself to allow the effect you are looking for... >>>>> >>>>> What I ultimately want is the ability to declare storage in extensions in >>>>> the same submodule. Combining that with fileprivate will allow the same >>>>> tricks without the indentation (together in their own file). This >>>>> nesting will help in the mean-time (and would still be useful after for >>>>> those who prefer to organize their code in fewer/longer files). I think >>>>> it could be helpful in other ways too… >>>> >>>> What do you think of `partial` types like C# but limited to a file? >>>> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx >>>> >>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html >>>> >>> >>> That's the direction the new proposal (0169) is going towards with >>> extensions in the same file. >> >> I don’t see how SE-0169 do that more than any other meaning private got >> until now. This was already the case with the initial meaning of private, >> and was the case with fileprivate. > > The current semantics of private don’t give any support for partial types > like in C# because the accessibility is restricted to the current scope. With > SE-0169’s private, extensions in the same file as the type share that scope. > Plus, the Alternatives Considered section of the proposal discusses potential > future directions where those extensions could look even more like C# > partials :)
SE-169 could be emulated cleanly by introducing partial types within the same scope as a new feature completely separate from extensions. Partial types would not require redefining how private or extensions work now. It would also serve as a way to communicate to the user that the type is not done being defined so if they want to encapsulate the type completely, They have to make it non partial. > >> And for file splitting and visibility control, we need submodules. Until >> then, if this proposal is to define the ultimate meaning of private, I >> rather like this meaning that the SE-0025 one. >> > > _______________________________________________ > 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
