<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On May 18, 2016, at 10:25 AM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">You should definitely submit your proposal first. I'll review your nesting rules later. f your proposal is accepted I will edit mine to match.<div><br></div><div>Allowing value types belong in a separate proposal; I think this is something people would want to discuss on their own merits. For example, the `class` keyword already exists, and can be used in several places to force something to be a class. People would want similar value type keywords to also work everywhere `class` does, not only in a composite type declaration.</div></div></div></blockquote><div><br></div>I agree about value types. I'm not sure what benefit that provides. What we really need here is the ability to constrain value semantics. Simply constraining to a value type does not do that (a struct can have a class property and use it in a way that violates value semantics). Dave A and I have had a pretty lengthy discussion of desirable se,antic guarantees recently.<div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 18, 2016 at 6:49 AM, Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I added a note to my proposal which makes it clear that the `Any<>` I proposed represents the simple/base form that Swift 3 should integrate, if accepted. Later `Any<>` could be enhanced without any breaking changes.</div><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> I’m not sure if your and my nesting rules do fit together, we might reconsider mine before the pull request is accepted.<div><br></div><div>- Also I don’t see the point why `<span style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;background-color:transparent;color:rgb(51,51,51)">Any<Any<ProtocolA, ProtocolB>></span>` this is illegal!?</div><div><br></div><div><span style="white-space:pre-wrap"> </span>`Any<>` proposed by me will allow that, even it its useless form the point of the readers view. This type is inferred to `<span style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;background-color:transparent;color:rgb(51,51,51)">Any<ProtocolA, ProtocolB></span>`.</div><div><br></div><div>Why do you not allow value types in your proposal?</div><span class=""><div><br></div><div> <div><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div></div></span></div><br>_______________________________________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></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></body></html>