oracular (3) Syntax::Operator::In.3pm.gz

Provided by: libsyntax-operator-in-perl_0.06-1build3_amd64 bug

NAME

       "Syntax::Operator::In" - infix element-of-list meta-operator

SYNOPSIS

       On Perl v5.38 or later:

          use Syntax::Operator::In;

          if($x in:eq @some_strings) {
             say "x is one of the given strings";
          }

DESCRIPTION

       This module provides an infix meta-operator that implements a element-of-list test on either strings or
       numbers.

       Support for custom infix operators was added in the Perl 5.37.x development cycle and is available from
       development release v5.37.7 onwards, and therefore in Perl v5.38 onwards. The documentation of
       XS::Parse::Infix describes the situation in more detail.

       While Perl versions before this do not support custom infix operators, they can still be used via
       "XS::Parse::Infix" and hence XS::Parse::Keyword.  Custom keywords which attempt to parse operator syntax
       may be able to use these.

       For operators that already specialize on string or numerical equality, see instead
       Syntax::Operator::Elem.

OPERATORS

   in
          my $present = $lhs in:OP @rhs;

          my $present = $lhs in<OP> @rhs;

       Yields true if the value on the lefhand side is equal to any of the values in the list on the right,
       according to some equality test operator "OP".

       This test operator must be either "eq" for string match, or "==" for number match, or any other custom
       infix operator that is registered in the "XPI_CLS_EQUALITY" classification.

       There are currently two accepted forms of the syntax for this operator, using either a prefix colon or a
       circumfix pair of angle-brackets. They are entirely identical in semantics, differing only in the
       surface-level syntax to notate them. This is because I'm still entirely undecided on which notation is
       better in terms of readable neatness, flexibility, parsing ambiguity and so on. This is somewhat of an
       experiment to see which will eventually win.

TODO

       •   Improve runtime performance of compiletime-constant sets of strings, by detecting when the RHS
           contains string constants and convert it into a hash lookup.

       •   Consider cross-module integration with Syntax::Keyword::Match, permitting

              match($val : elem) {
                 case(@arr_of_strings) { ... }
              }

           Or perhaps this would be too weird, and maybe "match/case" should have an "any-of" list/array
           matching ability itself. See also <https://rt.cpan.org/Ticket/Display.html?id=143482>.

AUTHOR

       Paul Evans <leonerd@leonerd.org.uk>