[llvm-dev] [RFC] Should we add isa_or_null<>?
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Sat Apr 6 09:44:28 PDT 2019
On Fri, Apr 5, 2019 at 5:15 AM Aaron Ballman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, Apr 4, 2019 at 12:58 PM Chris Lattner <clattner at nondot.org> wrote:
> > > On Apr 4, 2019, at 5:37 AM, Don Hinton via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > >
> > > I'd like to propose adding `isa_or_null<>` to replace the following
> usage pattern that's relatively common in conditionals:
> > >
> > > var && isa<T>(var) =>> isa_or_null<T>(var)
> > >
> > > And in particular when `var` is a method call which might be
> expensive, e.g.:
> > >
> > > X->foo() && isa<T>(X->foo()) =>> isa_or_null<T>(X->foo())
> > >
> > > The implementation could be a simple wrapper around isa<>, and while
> the IR produced is only slightly more efficient, the elimination of an
> extra call could be worthwhile.
> > I’d love to see this, I agree with downstream comments though that this
> name will be confusing. isa_and_nonnull<>. ?
> tbh, I don't think the proposed name will be all that confusing --
I am with David on this, this sounds like misleading naming to me, I would
expect true on null value when reading : if (isa_or_null<T>(var))
we're used to _or_null() returning "the right thing" when given null.
I think we're used to have "the right thing" because the name matches the
semantic: the "_or_null()" suffix matches the semantics a conversion
operator that returns nullptr on failure.
It does not translate with isa<> IMO.
> isa_and_nonnull<> is a bit of a weird name for me, but I could
> probably live with it. We could spell it nonnull_and_isa<> to reflect
> the order of the operations, but that sort of hides the important part
> of the API (the "isa" bit).
isa_nonnulll works fine for me, isa_and_nonnull is a bit verbose but seems
OK as well.
For nonnull_and_isa<T>(val) ; it starts to look strangely close to the
pattern !val && isa<T>(val) ; and I'm not sure it is really such a
readability improvement anymore?
> > -Chris
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev