[llvm-commits] [patch] allow ref->pointer through dyn_cast

[Chandler Carruth]

On Tue, May 1, 2012 at 11:14 AM, David Blaikie <dblaikie at gmail.com> wrote:

> > 1) it makes the behavior non-obvious from inspection: pointer-in,
> > pointer-out is a useful invariant.
>
> What other behavior could be implied here? dyn_cast can't accept null
> anyway, why would it take a pointer? (though I'm not removing the
> dyn_cast that takes a pointer for those that want to use it)
>
> > 2) it breaks symmetry with cast: cast already handles references, but it
> > returns a reference
>
> Cast doesn't need to represent failure so its in/out can be symmetric,
> dyn_cast's API (non-null pointer in, null pointer out) is already
> asymmetric & can be represented more concretely in the type system by
> ref in/pointer out.
>
> > 3) it breaks symmetry with dyn_cast_or_null: either this function
> accepts a
> > reference, which makes no sense at all, or it accepts different types
>
> It's a different contract, as demonstrated by the name - it shouldn't
> accept a reference, it should be pointer in/pointer out. (in some
> mystical world I'd just have dyn_cast on pointers have the "or_null"
> behavior and the dyn_cast on references have the new behavior I'm
> adding - but we use guaranteed non-null pointers far too pervasively
> for that)
>

In all three of these cases you're arguing essentially: but the semantics
are different, why not make the APIs different?

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.

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120501/64f792c3/attachment.html>