<div dir="ltr">Sub typing is the answer that we&#39;re going with then?<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 4, 2016 at 4:26 PM, T.J. Usiyan <span dir="ltr">&lt;<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><span style="font-size:13px">It could be a more general solution. I am unclear about what &#39;subtype relationships&#39; means here though.</span><div style="font-size:13px"><br></div><div style="font-size:13px">Are you talking a about what you allude to here? <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000525.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000525.html</a> </div><div style="font-size:13px"><br></div><div style="font-size:13px">The benefit of explicitly narrowing, in my opinion, is that there is no unnecessary cost to figuring out lookup. (Please correct me if I am mistaken.) Implicit promotions introduce uncertainty with regard to what a value is being treated as in any given moment. This uncertainty is worth it in many cases but I will suggest that it is not worth it when trying to deal with a narrower set of cases from an already established set. For example, in the graph/lattice situation, conversions must be written because there is no reasonable conversion that can be assumed. In this proposal, the conversion is obvious and trivial because the relationship is completely clear.</div><div style="font-size:13px"><br></div><div style="font-size:13px">All of that said, I *am* unclear about what subtype relationships means so it may very well be a better solution. It certainly sounds like a more general solution but I am not convinced that that is an advantage when trying to deal with a strict subset.</div><div class="gmail_extra"><br></div></span><div class="gmail_extra"><span class="HOEnZb"><font color="#888888">TJ<br></font></span><div class="gmail_quote"><span class="">On Sat, Jun 4, 2016 at 1:25 AM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>&gt;</span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr">Since this seems to have some interest, I&#39;ve made a gist.<div><br></div><div><a href="https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c" target="_blank">https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c</a></div></div></div></blockquote><br></div></span><div>We have frequently discussed introducing subtype relationships between structs and enums, in an effort to allow limited implicit promotions (e.g. from small integers to wider integers).  Wouldn’t that be a more general solution to this same problem?</div><span><font color="#888888"><div><br></div><div>-Chris</div><br></font></span></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>