search for: nonnull_and_isa

...t;_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...

...sing. isa_and_nonnull<>. ? tbh, I don't think the proposed name will be all that confusing -- we're used to _or_null() returning "the right thing" when given null. 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). ~Aaron > > -Chris >

...e "_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 l...

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

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

...ersion >> 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. >> > &g...

On Thu, Apr 4, 2019 at 7:10 PM Craig Topper <craig.topper at gmail.com> wrote: > Agreed that the new isa_or_null style is better. Just wanted mention the > other style so we know we should migrate those to the new one. > I have a checker under review that could be enhanced to do that -- though it currently replaces `X->foo() && isa<Y>(X->foo())` with

...sing. isa_and_nonnull<>. ? tbh, I don't think the proposed name will be all that confusing -- we're used to _or_null() returning "the right thing" when given null. 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). I think "isa_nonnull" would read fine too. To me, the extra "and" makes the ordering more of an issue. -- HT ~Aaron > > -Chris > _________...

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