<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>Two weeks ago there was a similar pitch here <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027643.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20161003/027643.html</a></p>
<p>In general I’m in favor of this feature, but I don’t know any technical issues this might have or does already have.</p>
<p>As I said in the other thread.</p>
<ul>
<li><p>I’m for nested everything.</p></li>
<li><p>Nested <code>extensions</code> to reduce noise at some point, BUT this should not remove <code>extension A.B { … }</code> completely. </p>
<pre><code class="swift">class A {
class B { … }
extension B { … } // extends A.B
}
</code></pre></li>
<li><p>We already have <code>A.B</code> syntax for extensions, why don’t we allow it for type declarations to reduce nesting (sometimes you don’t want to cluster everything)? Basically something like <code>class A.B { … }</code> would be a shortcut for <code>extension A { class B { … } }</code> and is bounded by the access modifier of <code>A</code>. (This is probably additive.)</p></li>
</ul>
<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_1476727943171306240" 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. Oktober 2016 um 19:59:54, Karl via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
I was just doing some googling, turns out there was a discussion
about nesting protocols in other types that seemed to go positively
a long time ago: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html</a>
<div class=""><br class=""></div>
<div class="">I would additionally like to propose that protocols
be allowed to contain nested types (including other protocols).
Relevant ABI issue is that the standard library contains enums for
“FloatingPointRoundingRule”, “FloatingPointClassification” and
“FloatingPointSign”. They would probably be better expressed as
“FloatingPoint.RoundingRule”, “.Sign", etc.</div>
<div class=""><br class=""></div>
<div class="">so to summarise, newly legal would be:</div>
<div class=""><br class=""></div>
<div class="">class MyClass {</div>
<div class=""><br class=""></div>
<div class=""> protocol Delegate {</div>
<div class=""> }</div>
<div class="">}</div>
<div class=""><br class=""></div>
<div class="">and also:</div>
<div class=""><br class=""></div>
<div class="">protocol MyProto {</div>
<div class=""><br class=""></div>
<div class=""> enum SomeValue {</div>
<div class=""> }</div>
<div class=""><br class=""></div>
<div class=""> protocol Delegate {</div>
<div class=""> associatedType
ExpectedContent</div>
<div class=""><br class=""></div>
<div class="">func receive(_: ExpectedContent, for:
SomeValue)</div>
<div class=""><br class=""></div>
<div class=""> protocol SecondaryTarget
{</div>
<div class=""> func
receive(_ : ExpectedContent)</div>
<div class=""> }</div>
<div class=""> }</div>
<div class="">}</div>
<div class=""><br class=""></div>
<div class="">When conforming to a nested protocol, you can just
use the name of the protocol:</div>
<div class=""><br class=""></div>
<div class="">class Host : MyProto.Delegate {</div>
<div class="">}</div>
<div class=""><br class=""></div>
<div class="">Except if a protocol in the chain has associated
types, then you must use a concrete, conforming type instead (as
you would in the first example — MyClass.Delegate):</div>
<div class=""><br class=""></div>
<div class="">class SecondaryProcessor : Host.SecondaryTarget
{</div>
<div class="">}</div>
<div class=""><br class=""></div>
<div class="">If we’re good with this, I’ll write up a
proposal.</div>
<div class="">
<div class="">
<div class=""><br class=""></div>
<div class="">- Karl</div>
</div>
</div>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>