<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>Disappointed to see that you just ignored everything I pitched to you. The proposal does not cover extensions nor it it sees the problem with access modifier which it creates.</p>

<pre><code>public protocol A {
     
    // Not allowed to use any access modifier here at all
    struct B {
        // Nor here
        var something: C = …
    }
}
</code></pre>

<p>Everything will be public here. Try to build a true singleton like this for example.</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_1478350325844196096" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">--&nbsp;<br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 5. November 2016 um 10:44:27, 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>


<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 2 Nov 2016, at 20:54, Slava Pestov &lt;<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>&gt;
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<blockquote type="cite" style="font-family: Helvetica; font-size: 12px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">
On Nov 2, 2016, at 8:32 AM, Paul Cantrell &lt;<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>&gt;
wrote:<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Oct 24, 2016, at 4:43 PM, Slava
Pestov &lt;<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>&gt; wrote:<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Oct 24, 2016, at 8:12 AM, Paul
Cantrell &lt;<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>&gt; wrote:<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Oct 24, 2016, at 5:09 AM, Slava
Pestov via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">
<br class="">
However protocols nested inside types and types nested inside
protocols is still not supported, because protocols introduce a
separate series of issues involving associated types and the ’Self’
type.<br class="">
<br class="">
The hard part of getting nested generics right is what to do if a
nested type ‘captures’ generic parameters of the outer type. For
non-protocol types, the behavior here is pretty
straightforward.<br class="">
<br class="">
If we allow protocols to be nested inside other types, we have to
decide what to do if the protocol ‘closes over’ generic parameters
of the outer type. For example,<br class="">
<br class="">
struct A&lt;T&gt; {<br class="">
protocol P {<br class="">
func requirement() -&gt; T<br class="">
}<br class="">
}<br class="">
<br class="">
Presumably A&lt;Int&gt;.P and A&lt;String&gt;.P are distinct types,
and A.P has a hidden associated type corresponding to the type
parameter ’T’?<br class="">
<br class="">
The other case is problematic too — the nested type might refer to
an associated type of the outer protocol:<br class="">
<br class="">
protocol P {<br class="">
associatedtype A<br class="">
<br class="">
struct T {<br class="">
var value: A<br class="">
}<br class="">
}<br class="">
<br class="">
Now writing P.T does not make sense, for the same reason that we
cannot form an existential of type P.A. We could prohibit
references to outer associated types of this form, or we could
figure out some way to give it a meaning. If C is a concrete type
conforming to P, then certainly C.T makes sense, for instance.
Internally, the nested type A.T could have a hidden ‘Self’ generic
type parameter, so that writing C.T is really the same as
P.T&lt;C&gt;.<br class="">
<br class="">
Protocols nested inside protocols also have the same
issue.<br class=""></blockquote>
<br class="">
FWIW, in almost all the situations where I’ve wanted to nest types
inside protocols and generic types, it’s only as a namespacing
convenience. Most often, it’s an enum type that’s used only by a
single method, and having it at the top of the module namespace
adds clutter.<br class="">
<br class="">
Here’s a real life example pared down. I wish I could do
this:<br class="">
<br class="">
public struct ResponseContentTransformer&lt;InputContentType,
OutputContentType&gt;: ResponseTransformer {<br class="">
<br class="">
&nbsp;&nbsp;public init(onInputTypeMismatch mismatchAction:
InputTypeMismatchAction = .error) {<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;...<br class="">
&nbsp;&nbsp;}<br class="">
<br class="">
&nbsp;&nbsp;public enum InputTypeMismatchAction { &nbsp;// Does not
depend on generic types above<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;case error<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;case skip<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;case skipIfOutputTypeMatches<br class="">
&nbsp;&nbsp;}<br class="">
<br class="">
}<br class="">
<br class="">
InputTypeMismatchAction is tightly associated with
ResponseContentTransformer, and is confusing as a top-level
type.<br class="">
<br class="">
What do you think about providing a “no captures” modifier for
nested types — like static inner classes in Java? Then Swift could
provide the namespace nesting I wish for this without having to
resolve the trickier type capture questions yet.<br class="">
<br class="">
Alternatively, what if (1) outer types aren’t capture unless
they’re referenced, and (2) nesting is only illegal if there’s a
capture? Then my code above would compile, as would this:<br class="">
<br class="">
public struct S&lt;T&gt; {<br class="">
&nbsp;&nbsp;public enum Foo {<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;case yin<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;case yang<br class="">
&nbsp;&nbsp;}<br class="">
}<br class="">
<br class="">
…but this wouldn’t:<br class="">
<br class="">
public struct S&lt;T&gt; {<br class="">
&nbsp;&nbsp;public enum Foo {<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;case yin(thing: T) &nbsp;// capture of T
illegal (for now)<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;case yang<br class="">
&nbsp;&nbsp;}<br class="">
}<br class="">
<br class="">
Either of these approaches would allow hygienic namespacing now
while leaving the door open to outer type capture in the
future.<br class=""></blockquote>
<br class="">
Yeah, this makes sense for a first cut at this feature.<br class="">
<br class="">
Slava<br class=""></blockquote>
<br class="">
Should I take a crack at writing up a proposal for this? Now? After
ABI work is done? (Probably the latter “OK if no captures”
approach?) Eager to help; don’t want to be in the way.<br class=""></blockquote>
<br style="font-family: Helvetica; font-size: 12px; 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;" class="">
<span style="font-family: Helvetica; font-size: 12px; 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; float: none; display: inline !important;" class="">Just speaking for myself and not the whole team — I think
you can submit the proposal at any time, we’re unlikely to get
around to doing it, if you want to take a crack that would be great
(again, with ‘no captures’ it’s “trivial”).</span><br style="font-family: Helvetica; font-size: 12px; 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;" class="">
<br style="font-family: Helvetica; font-size: 12px; 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;" class="">
<span style="font-family: Helvetica; font-size: 12px; 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; float: none; display: inline !important;" class="">Slava</span><br style="font-family: Helvetica; font-size: 12px; 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;" class="">
<br style="font-family: Helvetica; font-size: 12px; 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;" class="">
<blockquote type="cite" style="font-family: Helvetica; font-size: 12px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="">
P</blockquote>
</div>
</blockquote>
</div>
<br class="">
<div class=""><br class=""></div>
<div class="">Sorry, let this slip. Proposal sent -&nbsp;<a href="https://github.com/apple/swift-evolution/pull/552" class="">https://github.com/apple/swift-evolution/pull/552</a></div>
<div class=""><br class=""></div>
<div class="">- Karl</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>