[swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[Adrian Zubarev]

Wrong thread ;) If you think it’s ill-prepared than provide some feedback instead of just watching and waiting to throw negative feedback during review process.

There is a lot done, but it’s not visible to the public thread yet. Will be soon (by tomorrow I’d guess).

Thanks.



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalkovic at gmail.com) schrieb:

To me this is reminicent of what is happening with the T.Type / Type<T> story, where there seems to be a rush to throw a proposal under the cut-off date even if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:

I tried to tackle the ability to write extensions where everyone would be forced to write access modifier on member level. That’s what I had in my mind all the time. But the respond on this was, as you can see purely negative. :D

Making all extensions public when there is protocol conformance makes no sense, because you could extend your type with an internal protocol, or the extended type might be not public.

Anyways, I’m withdrawing this proposal. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell at pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers altogether, instead always specifying access at the member level. I would be interested in a proposal to improve the current model — perhaps, for example, making “public extension” apply only to a protocol conformance, and disabling access modifiers on extensions that don’t have a protocol conformance.
_______________________________________________
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/20160716/f96823f3/attachment.html>