r175796 - Replace CFGElement llvm::cast support to be well-defined.

[Ted Kremenek]

On Feb 22, 2013, at 9:53 AM, Douglas Gregor <dgregor at apple.com> wrote:

>> 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".
> 
> 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.
> 
> 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.

Right.  I also think "invalid" has different meanings for some of our types.

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.

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".

> 
>> 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.
> 
> 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.

Agreed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130222/29c421cd/attachment.html>