<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><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 class=""><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 class="h5"><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">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>