<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I see, that makes totally sense. I thought about `inout` only in terms of mutation not reassignment from within the scope itself.</div> <br> <div id="bloop_sign_1512931601332339968" class="bloop_sign"></div> <br><p class="airmail_on">Am 10. Dezember 2017 um 17:56:56, Jonathan Keller (<a href="mailto:jkeller234@icloud.com">jkeller234@icloud.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div dir="auto"><div></div><div>
<title></title>
No, inout should *not* be covariant, since foo can assign any
subtype of P to its parameter, not just F:
<div><br></div>
<div>protocol P {}</div>
<div>struct F: P {}</div>
<div>struct G: P {}</div>
<div><br></div>
<div>func foo(_ p: inout P) {</div>
<div> p = G()</div>
<div>}</div>
<div><br></div>
<div>var f = F()</div>
<div>foo(&f) // assigns a value of type G to a variable of type
F</div>
<div><br></div>
<div>
<div>
<div>From Jonathan</div>
</div>
<div><br>
On Dec 10, 2017, at 12:51 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>Hello Matthew, I have more more question about the generalized
supertype constraints. Does the generalization also covers
<code>inout</code>? I found a really annoying case with
<code>inout</code>.</p>
<pre><code class="swift">protocol P {}
func foo(_ p: inout P) {
print(p)
}
struct F : P {}
var f = F()
foo(&f) // won't compile until we explicitly write `var f: P = F()`
</code></pre>
<p>Shouldn’t we allow <code>inout</code> to have subtypes as well,
like <code>inout F : inout P</code>?</p>
<p>This is actually one of the pain points with the generic version
of the <code>print</code> function. We cannot pass an arbitrary
<code>TextOutputStream</code> to it without sacrificing the type. I
doubt the generic <code>print</code> function is justified, because
<code>TextOuputStream</code> does not have associated types nor a
<code>Self</code> constraint. Furthermore it forces you to create a
custom type-erased wrapper that can hold an arbitrary
<code>TextOutputSteram</code>.</p>
<p>If this is part of a totally different topic, I’ll move it in
it’s own thread.</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>
<div id="bloop_sign_1512894629399404032" class="bloop_sign"></div>
<br>
<p class="airmail_on">Am 2. Dezember 2017 um 19:03:24, Matthew
Johnson via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div><span>This thread received very light, but positive feedback.
I would really like to see this feature added and am willing
to draft and official proposal but am not able to implement it.
If anyone is interested in collaborating just let me
know.</span>
<div class=""><span><br class=""></span></div>
<div class=""><span><br class=""></span>
<div>
<blockquote type="cite" class="">
<div class=""><span>On Nov 24, 2017, at 5:03 PM, Matthew Johnson
via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span></div>
<span><br class="Apple-interchange-newline"></span>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span>One of the most frequent frustrations I encounter
when writing generic code in Swift is the requirement that
supertype constraints be concrete. When I mentioned this on
Twitter (<a href="https://twitter.com/anandabits/status/929958479598534656" class="">https://twitter.com/anandabits/status/929958479598534656</a>)
Doug Gregor mentioned that this feature is smaller and mostly
straightforward to design and implement (<a href="https://twitter.com/dgregor79/status/929975472779288576" class="">https://twitter.com/dgregor79/status/929975472779288576</a>).</span>
<div class="">
<div class=""><span><br class=""></span></div>
<div class=""><span>I currently have a PR open to add the
high-level description of this feature found below to the generics
manifesto (<a href="https://github.com/apple/swift/pull/13012" class="">https://github.com/apple/swift/pull/13012</a>):</span></div>
<div class=""><span><br class=""></span></div>
<div class="">
<div class=""><span>Currently, supertype constraints may only be
specified using a concrete class or protocol type. This
prevents us from abstracting over the supertype.</span></div>
<div class=""><span><br class=""></span></div>
<div class=""><span>```swift</span></div>
<div class=""><span>protocol P {</span></div>
<div class=""><span> associatedtype Base</span></div>
<div class=""><span> associatedtype Derived:
Base</span></div>
<div class=""><span>}</span></div>
<div class=""><span>```</span></div>
<div class=""><span><br class=""></span></div>
<div class=""><span>In the above example `Base` may be any type.
`Derived` may be the same as `Base` or may be _any_ subtype
of `Base`. All subtype relationships supported by Swift
should be supported in this context including, but not limited to,
classes and subclasses, existentials and conforming concrete types
or refining existentials, `T?` and `T`, `((Base) -> Void)`
and `((Derived) -> Void)`, etc.</span></div>
<div class=""><span><br class=""></span></div>
<div class=""><span>Generalized supertype constraints would be
accepted in all syntactic locations where generic constraints are
accepted.</span></div>
</div>
<div class=""><span><br class=""></span></div>
<div class=""><span>I would like to see generalized supertype
constraints make it into Swift 5 if possible. I am not an
implementer so I will not be able to bring a proposal forward alone
but am interested in collaborating with anyone interested in
working on implementation.</span></div>
<div class=""><span><br class=""></span></div>
<div class=""><span>I am also interested in hearing general
feedback on this feature from the community at large. Have
you also found this limitation frustrating? In what contexts?
Does anyone have reservations about introducing this
capability? If so, what are they?</span>
<div class=""><span><br class=""></span></div>
<div class="">
<div class=""><span>Matthew</span></div>
<div class="">
<div class=""><span><br class=""></span></div>
</div>
</div>
</div>
</div>
</div>
<span>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</span></div>
</blockquote>
</div>
<span><br class=""></span></div>
<span>_______________________________________________<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">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</span></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></span></blockquote></body></html>