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

[David Blaikie]

On Tue, May 1, 2012 at 11:20 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 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.

The point would be that semantic models are easier to learn when
they're expressed in the API - you use the API & you're bound to get
it right. But I don't think there's much more I can contribute to this
so I'll let it be unless someone else has any thoughts to add.

- David