[swift-evolution] [Proposal] Revising access modifiers on extensions

L. Mihalkovic laurent.mihalkovic at gmail.com
Mon Jun 27 15:15:48 CDT 2016


"The access modifier of an extension sets the default modifier of its members which has no modifier applied to them."

I cannot understand the sentence, or the following:

"If there the extension has no access modifier, then the default modifier of its members which has no explicit modifier will be internal if the extended type is either public or internal, or it will be private when the extended type is private(analogous for fileprivate)."

But more importantly, I was under the impression that Doug had hinted that private (or likely more generally scoped) conformance on extension was a slipery slope with important impact on runtime performance.

Regards
(From mobile)

> On Jun 27, 2016, at 2:39 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I completely rewritten the proposal, you can read the formatted version here:
> 
> https://github.com/DevAndArtist/swift-evolution/blob/19f2583209a5763880e6f6fa6738ea0c6011f2d6/proposals/nnnn-extensions-access-modifiers.md
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 27. Juni 2016 um 12:58:53, Adrian Zubarev (adrian.zubarev at devandartist.com) schrieb:
> 
>> And yet another correction of the default protocol implementations part of my reply.
>> 
>> The imported module is correct, but the default implementation is not imported (I relied on Xcode which didn’t raise an error before I started building the project where I was using the module, and I didn’t build it at the first time).
>> 
>> So we’d need to implement foo by ourself.
>> 
>> struct B : A {
>>       
>>     public func foo() {}
>> }   
>> The rest of my reply should be fine. With the same access control it would be more clearer and intuitive how the extension will be imported.
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 27. Juni 2016 um 10:38:12, Adrian Zubarev (adrian.zubarev at devandartist.com) schrieb:
>> 
>>> Lets examine the impact on default protocol implementations:
>>> 
>>> Currently we have this behavior:
>>> 
>>> public protocol A {
>>>     func foo()
>>> }
>>> 
>>> extension A {
>>>     func foo() { /* implement */ }    
>>> }
>>> The imported version would look like this.
>>> 
>>> public protocol A {
>>>     public func foo()
>>> }
>>> As the module user you have no clue that there might be a default implementation, but you sill will be able to use it, because when conforming to A you don’t have to implement foo. This implicitly signals you that there is indeed a default implemenation
>>> 
>>> struct B : A {} // This will be enough
>>> 
>>> A().foo() // this is fine
>>> One could signal the module user that there is a default implementation by making the extension explicit public as well.
>>> 
>>> // explicitly marked as public to grant visibility to    
>>> // the default implementation extension bag
>>> public extension A {
>>>        
>>>     /// will do something cool
>>>     func foo() { /* implement */ }    
>>> }
>>> The result of the imported module would change and look like this:
>>> 
>>> public protocol A {
>>>     public func foo()
>>> }
>>> 
>>> extension A {
>>>        
>>>     /// will do something cool
>>>     public func foo()
>>> }
>>> With the proposed change all default implementations will become visible by default and I think this is great step as well.
>>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/905222e4/attachment-0001.html>


More information about the swift-evolution mailing list