<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>That’s what this mailing list is for. To discuss everything with the community and the core team behind Swift. If you don’t try, you won’t get anything. If everyone would be afraid to tackle something that might go really wrong during review, nothing will happen at all. We’ll end up with a language that is driven by the core team where the community would be to afraid to step in.</p>
<p>Which ‘Type<t> proposal’ exactly are you referring here?</t></p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1468753075059684864" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 17. Juli 2016 um 12:50:32, L. Mihalkovic (<a href="mailto:laurent.mihalkovic@gmail.com">laurent.mihalkovic@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div dir="auto"><div></div><div>
<title></title>
<div>
<div>
<div><br>
<br>
<div>Regards</div>
(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"> mobile)</span></div>
<div><br>
On Jul 17, 2016, at 8:07 AM, Adrian Zubarev via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div class="bloop_markdown">
<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>
<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>
</div>
</div>
</blockquote>
<div>I thought I had clearly shared my personal view (not any
truth) in the other thread. IMVHO Type<T> is ill-prepared for
addressing the topic of reflection. Some of the ideas are there of
course simply because it is obvious that swift currently has a gap
in this area and some of the pieces of a reflection API are obvious
in nature. But the proposal does not propose a cohesive vision of
which Type<T> would be a small step, paving the way for the
rest being additive later. </div>
<div>When dealing with reflection, the first step should IMHO be to
understand the 2 facets it takes (there is plenty of literature and
research papers on the topic) to give a frame of reference to the
solution, and then proceed with the code that will deliver the
solution. Starting from the ground up with a single class and
saying 'the rest will organize itself around' is asking a lot out
of lady luck, and has a very high chance of creating more 'oops we
didn't think about that' moments like recently happened with 0111 a
week ago, or with other proposals hitting snags at the
implementattion stage.</div>
<div>This is not unlike what happened with Any<P,Q> and all
the subsequent debating.. I had offered early on that before
fixating on the downstream details, a fundamental question had to
be answered: whether or not to carry the semantic on a container,
versus expressing it directly in the grammar. Any possible detailed
syntax would just be the materialization of either of these two
core choices. Instead of answering this question first -it has to
do with the fundamental feel or the language, as well as deep
implications for the compiler, and as such could only be answered
by the core team- weeks of banter went on for no valuable outcome.
IMHO this is even critical for the design of a reflection API, and
i have no desire to participate in was I see as improductive
without the core team making the early decisions they only can
make.</div>
<div><br></div>
<br>
<blockquote type="cite">
<div>
<div class="bloop_markdown"></div>
<div class="bloop_original_html">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<br></div>
<br>
<div id="bloop_sign_1468734362672637952" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<br>
<p class="airmail_on">Am 17. Juli 2016 um 05:30:28, L. Mihalkovic
(<a href="mailto:laurent.mihalkovic@gmail.com">laurent.mihalkovic@gmail.com</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<div dir="auto">
<div>
<div><span><br></span>
<div><span>Regards</span></div>
<span>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.294118);"> mobile)</span></span></div>
<div><br>
On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div class="bloop_markdown">
<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 class="bloop_markdown"></div>
<div class="bloop_original_html">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<br></div>
<br>
<div id="bloop_sign_1468697550460689152" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<br>
<p class="airmail_on">Am 16. Juli 2016 um 21:21:59, L. Mihalkovic
(<a href="mailto:laurent.mihalkovic@gmail.com">laurent.mihalkovic@gmail.com</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<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 class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.294118);"> 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">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div class="bloop_markdown">
<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 class="bloop_original_html">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<br></div>
<br>
<div id="bloop_sign_1468689070988345088" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<br>
<p class="airmail_on">Am 16. Juli 2016 um 19:09:09, Paul Cantrell
(<a href="mailto:cantrell@pobox.com">cantrell@pobox.com</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<div><span><span style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 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 class="bloop_markdown"></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">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<div class="bloop_markdown"></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">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<div class="bloop_markdown"></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">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
</div>
</div>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>