Can you elaborate? What understanding of extensions is lacking in this proposal?<br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 16, 2016 at 22:30 L. Mihalkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><div>Regards</div>(From<span> mobile)</span></div></div><div dir="auto"><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 dir="auto"><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></div><div dir="auto"><blockquote type="cite"><div><div>
<p></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 21:21:59, 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>
<div>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>
<div>Regards</div>
(From<span> mobile)</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></span></blockquote></div><div><p></p></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>_______________________________________________<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>
</blockquote></div>