New API function idea: newLISTOPn()

I quite often find myself writing nontrivially-sized chunks of C code
that construct optree fragments. If the optree contains only base OPs,
UNOPs, BINOPs or LOGOPs then you can usually write the entire tree in a
big nested shape of C code. But not so for LISTOPs, because of the
annoying inconvenience of having to go construct a plain OP_LIST and
then op_convert_list() it to the target type. This results in noisy
code that's hard to read the intent of; e.g.:

  OP *checkop = newLISTOP(OP_LIST, 0, NULL, NULL);
  checkop = op_append_elem(OP_LIST, checkop,
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkobj)));
  checkop = op_append_elem(OP_LIST, checkop,
      newSLUGOP(1));
  checkop = op_append_elem(OP_LIST, checkop,
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkcv)));

  checkop = op_convert_list(OP_ENTERSUB, G_VOID, checkop);

I propose that now we have C99 and we can use __VA_LIST__ in macros, we
could neaten this up enormously into:

  OP *checkop = newLISTOPn(OP_ENTERSUB, G_VOID,
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkobj)),
      newSLUGOP(1),
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkcv)));

This basically requires making a valist-taking function, and wrapping
it in a macro thus:

  #define newLISTOPn(type, flags, ...)  \
      Perl_newLISTOPn(aTHX_ type, flags, __VA_ARGS__, NULL)

Since we already have macros that use __VA_ARGS__, I don't imagine this
will be problematic. I expect that, as well as providing a handy
shortcut for XS modules and the like, there's probably quite a few
places in core code that could be similarly neatened by it.

Before I write up a quick little PR to add this, can anyone spot a
reason why not to?

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

• New API function idea: newLISTOPn() by Paul "LeoNerd" Evans
• Re: New API function idea: newLISTOPn() by Paul "LeoNerd" Evans