<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 4:08 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">On Feb 22, 2013, at 9:53 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>> wrote:<br>
</div><div><div class="im"><br><blockquote type="cite"><div style="word-wrap:break-word"><blockquote type="cite" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">My only concern is that there's already a sense of invalidity for CFGElement and TypeLocs that's publicly usable, so now the APIs would be returning Optional<T> where T is (without any type safety helping in this case) guaranteed to be "not invalid".<br>
</div></div></div></blockquote><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
That's my main concern. If you have a type that has an invalid state, you have to be aware when objects of that type has invalid state. If we then wrap an Optional<> around it, now you have two axes of invalid state to worry about… which is actively confusing. So, for types that already have an invalid state, I'd rather not have getAs<> return an Optional<> because we'd end up with the two axes of invalidity. For types that *don't* have an invalid state, returning Optional<> from getAs<> would be a great solution.</div>
<div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
And if we can eliminate the invalid states for some types, switching over to Optional<> for the places where do getAs<> and similar operations, I think that would improve the clarity of the code base.</div></div>
</blockquote></div></div></div></blockquote><div style>Excellent - fixed CFG* hierarchy to remove the invalid state & use Optional<CFG*> instead in r175938.<br><br>I might consider what it'll take to transform TypeLoc in a similar way at some point in the future.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">
<div><span style="color:rgb(34,34,34)">Right.  I also think "invalid" has different meanings for some of our types.</span><br></div></div></div></blockquote><div><br></div><div style>Yep, it's by no means a global solution & it wasn't obvious to me which 'invalid' states were invalid enough to remove/replace with Optional. We'll take them on a case-by-case basis.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>For example, for SourceLocation "invalid" means that there is no location, but that still is a legal location that can be *used*.  In the case of CFGStmt, and invalid CFGStmt is one that can't be used at all; it's tantamount to a dangling pointer.<br>
</div><div><br></div><div>Another analogy is the difference between "the empty set" and "no set".  They are completely different concepts.  I think in our codebase the term "validity" is sometimes used for one or the other.  For me, Optional<> maps to "no set" or "there is a set".</div>
<div class="im"><div><br></div><blockquote type="cite"><div style="word-wrap:break-word"><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<blockquote type="cite" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">So here's a hypothetical step further: along with specializing Optional to use zero-cost "optionality" (I suppose that would negate the concern I have above - essentially Optional<T> would be another representation for "invalid T"), make it so that no code deals with raw invalid Ts (the only place where invalid Ts could be constructed would be in Optional, via friending). That way we get zero cost type safe invalid states.</div>
</div></div></blockquote><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Making Optional<T> have zero space cost when possible would be a great optimization. I'd consider that orthogonal to the design discussion, because I don't think we're motivated either way by the current cost of Optional.</span></div>
</blockquote></div></div><br><div>Agreed.</div></div></blockquote><div style><br>Fair point - I've left that as an exercise for the future (for me or someone else). None of the Optional<CFG*> were members so the extra space consumption is only a minor stack issue by the looks of it.<br>
<br>- David </div></div><br></div></div>