<div dir="ltr">On Sun, Jul 17, 2016 at 1:42 PM, Jose Cheyo Jimenez <span dir="ltr"><<a href="mailto:cheyo@masters3d.com" target="_blank">cheyo@masters3d.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div></div><div><br></div><div><br>On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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><p>My first draft had some mistakes related access modifier on extension but the final proposal does fully understands how they work and aims to eliminate <code>default access modifier</code> behavior. </p>
<p>There is no default access modifier on other types like classes etc. So why should there be any on extensions I’d ask you. The Swift folks here were just whining and arguing with their laziness on typing out and repeating access modifier on each extension member.</p>
<p>Jordan was in favor of removing them completely, but argued that “he knows some people that would still want the <code>default access modifier</code> to be there.”</p>
<p>Right now access modifier on extensions are an ugly shake from how they work with protocols combined with access modifier of classes etc. (On protocols they just like default access modifier, but you cannot override them member wise.)</p>
<p>I didn’t want to remove them completely, but allow to set the visibility boundary to the outside world.</p>
<ul>
<li><code>public extension</code> - visible to everywhere.</li>
<li><code>internal extension</code> - member cannot be <code>public</code> and therefore the implementation is only visible for the whole module.</li>
<li><code>private/fileprivate extension</code> - the extension member are only visible to the current file.</li>
</ul>
<p>And yes with this model you’d need to repeat correct access modifier member wise, but some folks already do that with extensions and everyone does it with classes, structs and enums.</p>
<p>Again that concept is not about being able to refer to extensions. It’s about the visibility boundary set by their access modifier, which is also bounded by the access modifier of the extended type in respect with the protocol conformance that might be applied on that extension.</p></div></div></blockquote><div><br></div><div>Well, let's see if my draft gains traction. I hope it addresses some/most of these concerns of yours. I'm trying to incorporate all of the feedback I got today and hopefully will have something improved by tomorrow.</div></div></div></div></div></blockquote><div><br></div></span>I don't think it would be good thing to propose (even as an alternative), the complete removal of access modifiers again in a new proposal.</div></blockquote><div><br></div><div>I have been swinging back and forth about whether removal should be the proposed solution; right now, I'm leaning again towards your view (i.e. that it shouldn't be the proposed solution, because it gets rid of some features that people like which aren't doing harm).</div><div><br></div><div>I would expect that it should show up as an alternative because, well, it is an alternative. We should have a formal paper trail of the design alternatives explored and reasons why the community and core team accept or reject them; otherwise, it could come up again.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">A better approach would be to cut to the heart of the issue (public access modifier) and cut the scope to the smallest possible subset requirements to make that work. I do think we need to be able to declare some things with a higher access modifier inside extensions (even though their effective scope will be less) in order to make `private extension` work with implicitly internal methods that effectively have fileprivate access. </div></blockquote><div><br></div><div>Right, I will limit the proposal to those two issues.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I think this new proposal will definitely would have a better chance of acceptance by keeping extension in making all methods inside the extension to be internal and still force public method to be explicit like everywhere else.</div></div></blockquote><div><br></div><div>Great. I will aim to complete a revised draft this evening.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div> <div><div class="h5"><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><p>If someone don’t get my intension right, I’m sorry for that. I’m a programmer not a book author and I can’t write something spectacular looking arguments like Mr. Mihalkovic does.</p>
<p>That said, thats not related to your first comment about <code>Type<T></code>, nor it does help here anyone. I feel like I’m reading philosophical books when reading comments that don’t have a clear answer on a particular topic/question. It’s more like wrapping the topic around with some flowers. </p>
<p></p></div><div><span><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br></span><div><div><p>Am 17. Juli 2016 um 05:30:28, L. Mihalkovic (<a href="mailto:laurent.mihalkovic@gmail.com" target="_blank">laurent.mihalkovic@gmail.com</a>) schrieb:</p> <blockquote type="cite"><span><div dir="auto"><div></div><div>
<div><br>
<div>Regards</div>
(From<span> mobile)</span></div>
<div><br>
On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div>
<p>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.</p>
<p>There is a lot done, but it’s not visible to the public thread
yet. Will be soon (by tomorrow I’d guess).</p>
<p>Thanks.</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>
<div><span style="background-color:rgba(255,255,255,0)">A
question i regularly ponder on with modern opensource is how it
went so fast from stallman writting gcc to today's anything-goes,
where there seems to be an expectatation that throwing even the
worst unfinished piece of code in the public should implicitely gag
others, and only compel them to have to fix it. </span></div>
<div><span style="background-color:rgba(255,255,255,0)">There
has always been great as well as ludicrous ideas in the history of
mankind, and it would be a rare privilege of the opensource
movement that the latter ought not to be singled out as such, and
have them become by their mere presence in the public, everyone's
responsibility to improve upon. </span></div>
<div><span style="background-color:rgba(255,255,255,0)">This
proposal was based on a lack of understanding of extensions. My
understand of the process is that the initial discussion phase is
there to evaluate an idea leaving, only the promissing ones reach
proposal stage.</span></div>
</div>
<blockquote type="cite">
<div>
<div></div>
<div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<br>
<div>
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<br>
<p>Am 16. Juli 2016 um 21:21:59, L. Mihalkovic
(<a href="mailto:laurent.mihalkovic@gmail.com" target="_blank">laurent.mihalkovic@gmail.com</a>)
schrieb:</p>
<blockquote type="cite">
<div dir="auto">
<div>
<div>
<div><span>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.<br></span>
<div><span>Regards</span></div>
<span>(From<span> mobile)</span></span></div>
<div><br>
On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div>
<p>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</p>
<p>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.</p>
<p>Anyways, I’m withdrawing this proposal. :)</p>
</div>
<div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<br>
<div>
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<br>
<p>Am 16. Juli 2016 um 19:09:09, Paul Cantrell
(<a href="mailto:cantrell@pobox.com" target="_blank">cantrell@pobox.com</a>)
schrieb:</p>
<blockquote type="cite">
<div><span><span style="color:rgb(0,0,0);font-family:'helvetica Neue',helvetica;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none">
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.</span></span></div>
</blockquote>
</div>
<div></div>
</div>
</blockquote>
<blockquote type="cite">
<div>
<span>_______________________________________________</span><br>
<span>swift-evolution mailing list</span><br>
<span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<div></div>
</div>
</blockquote>
<blockquote type="cite">
<div>
<span>_______________________________________________</span><br>
<span>swift-evolution mailing list</span><br>
<span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
</div></div></span></blockquote></div></div></div><div><p></p></div></div><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></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></div></div></blockquote></div><br></div></div>