<div class="gmail_quote">On Tue, May 1, 2012 at 11:14 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> 1) it makes the behavior non-obvious from inspection: pointer-in,<br>
> pointer-out is a useful invariant.<br>
<br>
</div>What other behavior could be implied here? dyn_cast can't accept null<br>
anyway, why would it take a pointer? (though I'm not removing the<br>
dyn_cast that takes a pointer for those that want to use it)<br>
<div class="im"><br>
> 2) it breaks symmetry with cast: cast already handles references, but it<br>
> returns a reference<br>
<br>
</div>Cast doesn't need to represent failure so its in/out can be symmetric,<br>
dyn_cast's API (non-null pointer in, null pointer out) is already<br>
asymmetric & can be represented more concretely in the type system by<br>
ref in/pointer out.<br>
<div class="im"><br>
> 3) it breaks symmetry with dyn_cast_or_null: either this function accepts a<br>
> reference, which makes no sense at all, or it accepts different types<br>
<br>
</div>It's a different contract, as demonstrated by the name - it shouldn't<br>
accept a reference, it should be pointer in/pointer out. (in some<br>
mystical world I'd just have dyn_cast on pointers have the "or_null"<br>
behavior and the dyn_cast on references have the new behavior I'm<br>
adding - but we use guaranteed non-null pointers far too pervasively<br>
for that)<br>
<div class="im"></div></blockquote></div><br><div>In all three of these cases you're arguing essentially: but the semantics are different, why not make the APIs different?</div><div><br></div><div>Because different APIs increase the burden of learning, using, and working with the interfaces as a whole. I think that having cast, dyn_cast, isa, and dyn_cast_or_null all having symmetric, similar interface contracts makes it much easier to reason about them. I don't have to learn 4 different patterns, I learn one pattern for the interfaces, and 4 semantic models.</div>
<div><br></div><div>I don't see what problem this solves that is so large as to make loss of similarity and clarity in the interfaces worthwhile. Certainly, iterators, or avoiding a '&' in a few places don't seem to cut it...</div>