llvm dev - May 2019 - [RFC] Should we add isa_or_null<>?

On Mon, Apr 29, 2019, 02:37 David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 22/04/2019 15:15, Don Hinton via llvm-dev wrote:
> > Although there were a few no votes, it looks like there's a
consensus
> > for adding a `isa_and_nonnull` type operator.  While there were some
who
> > preferred `isa_nonnull`, it wasn't overwhelming, and since
> > `isa_and_nonnull` is already committed, I'm going to leave it as
> > `isa_and_nonnull` for the time being.
>
> Maybe I missed something, but it looked to me as if the consensus was
> that `isa_and_some_words<T>(foo)` imposed a higher cognitive load on
the
> reader than `foo && isa<T>(foo)`, as well as being more to
type in most
> cases, so wasn't worth adding.
>
FWIW, I agree with this and Bogner: this doesn't seem like an improvement
worth the cost.

> David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190504/6b276102/attachment.html>

+1, if we're voting. I don't think it adds to the readability of code
for me personally.

On Sat, May 4, 2019 at 11:47 AM Chandler Carruth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On Mon, Apr 29, 2019, 02:37 David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> On 22/04/2019 15:15, Don Hinton via llvm-dev wrote:
>> > Although there were a few no votes, it looks like there's a
consensus
>> > for adding a `isa_and_nonnull` type operator.  While there were
some who
>> > preferred `isa_nonnull`, it wasn't overwhelming, and since
>> > `isa_and_nonnull` is already committed, I'm going to leave it
as
>> > `isa_and_nonnull` for the time being.
>>
>> Maybe I missed something, but it looked to me as if the consensus was
>> that `isa_and_some_words<T>(foo)` imposed a higher cognitive load
on the
>> reader than `foo && isa<T>(foo)`, as well as being more
to type in most
>> cases, so wasn't worth adding.
>
>
> FWIW, I agree with this and Bogner: this doesn't seem like an
improvement worth the cost.
>
>>
>> David
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

+1 on not adding the new API

On Sat, May 4, 2019, 11:51 AM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +1, if we're voting. I don't think it adds to the readability of
code
> for me personally.
>
> On Sat, May 4, 2019 at 11:47 AM Chandler Carruth via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > On Mon, Apr 29, 2019, 02:37 David Chisnall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> On 22/04/2019 15:15, Don Hinton via llvm-dev wrote:
> >> > Although there were a few no votes, it looks like there's
a consensus
> >> > for adding a `isa_and_nonnull` type operator.  While there
were some
> who
> >> > preferred `isa_nonnull`, it wasn't overwhelming, and
since
> >> > `isa_and_nonnull` is already committed, I'm going to
leave it as
> >> > `isa_and_nonnull` for the time being.
> >>
> >> Maybe I missed something, but it looked to me as if the consensus
was
> >> that `isa_and_some_words<T>(foo)` imposed a higher cognitive
load on the
> >> reader than `foo && isa<T>(foo)`, as well as being
more to type in most
> >> cases, so wasn't worth adding.
> >
> >
> > FWIW, I agree with this and Bogner: this doesn't seem like an
> improvement worth the cost.
> >
> >>
> >> David
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190504/2310724f/attachment.html>